>I’m still using a paid third party AV for this sole reason.
Would you mind naming it? AFAIK most third party anti-malware solutions act like rootkits, possibly introducing new attack vectors, or have become basically ad-ware and malware themselves trying yo bait you in various subscriptions.
I’m using Nod32 from Eset for almost a decade now.
All AV somehow have to hook into low level system calls so can’t really avoid the kernel driver. Nonetheless, nod32 has been an install and forget AV with no interruption nor bait/nag screen at all. It’s a no bullshit AV and it does well.
I supposedly get the same protection as Defender (according to various AV tests review) and most importantly I get the IO performance back.
> All AV somehow have to hook into low level system calls so can’t really avoid the kernel driver.
While I don’t doubt this true for Windows, on macOS Apple is phasing out kernel modules with APIs that allow software to hook into those low level calls without actually running in the kernel. For AV vendors there’s the Endpoint Security System Extension: https://developer.apple.com/documentation/endpointsecurity
All the AV/endpoint security solutions I’ve seen have switched to this.
I don't really see a difference, as a consumer. If the AV sits at the kernel level or between userspace and kernel, it's still sitting below userspace and can do whatever it wants to the system. Sure, if I trust the kernel is better written than the AV software, I may have a few extra guarantees, but that is not a given and anyway it doesn't mean I can confidently run an AV I think may be poorly written.
It overall seems like a more complex solution that has more chances of being wrong. I would bet the core reason Apple did it was control to lock down their own control of your OS, not any security reason. Perhaps it also simplifies their development somewhat, if they can rid of some stability guarantees for some in-kernel APIs that AV would have needed.
> it's still sitting below user space and can do whatever it wants to the system.
I don't know much about the Endpoint Security extension, but for Apple's network filtering extension they actually DO address this!
The code that runs on every network call is heavily sandboxed and can't communicate at all with the outside. Its only action is emitting some basic signal like "block" or "accept". This means that while the system extension can evaluate all your network communication, and block what it chooses, it can't exfiltrate the specific content. I might have the details wrong, but that's the general intention.
But the security benefits aside, I think the real reason for preventing code from running in the kernel is about stability and not security. Buggy code won't crash the system anymore. They can also enforce stricter performance requirements.
(And at the moment, you can still run kernel extensions on your own system if you really want by disabling SIP and other things, it's just infeasible for any AV vendor to have their customers step through that very onerous process.)
That's also what I'm using and for the same reasons. Defender's protection is fine according to testing, but the IO performance is insanely bad. I wouldn't bother with running ESET's AV if Defender didn't slow heavy disk IO operations to a crawl. And I'm not excluding any development directories because malicious code can come in either as part of the project I just pulled down from github or from pulling in one of its dependencies from a package index.
Would you mind naming it? AFAIK most third party anti-malware solutions act like rootkits, possibly introducing new attack vectors, or have become basically ad-ware and malware themselves trying yo bait you in various subscriptions.