[Reason077]

Are they? Apple has pretty much banned kernel drivers (kexts) in macOS on Apple Silicon. When they were still used, they were a common cause of crashes and instability, not to mention potential gaping security holes.

Most things that third-party kernel drivers used to do (device drivers, file systems, etc) are now done just as well, and much more safely, in userspace. I'm surprised if Microsoft isn't heading in this direction too?

Presumably, Crowdstrike runs on macOS without a kernel extension?

[cywick]

> Presumably, Crowdstrike runs on macOS without a kernel extension?

That's correct: CrowdStrike now only installs an "Endpoint Security" system extension and a "Network" system extension on macOS, but no kernel extension anymore.

[tankenmate]

One would hope that Crowdstrike does a similar thing on Linux and relies on fanotify and/or ebpf instead of using a kernel module. The other upside to this would be not having to wait for Crowdstrike to be constantly updating their code for newer kernels.

[BodyCulture]

Wait, you still will be using CS? Why?

[wjdp]

I believe so but would like better details. We used to use another provider that depended on exact kernel versions whereas the falcon-sensor seems quite happy with kernel updates.

[lucasRW]

Whatever protection is implemented in user-land can be removed from user-land too. This is why most EDR vendors are now gradually relying on kernel based mechanisms rather than doing stuff like injecting their DLL in a process, hooking syscalls, etc...

[JackSlateur]

This is wrong, there are many facilities that, once applied, cannot be modified (unless reboot)

[lucasRW]

Such as ?

[JackSlateur]

Random example: https://man.openbsd.org/OpenBSD-7.3/msyscall

This is a syscall used by userspace to tell the kernel which memory portion is allowed to do syscalls

This syscall can only be used once : once the linker has done it, the kernel will refuse extra calls (so allowing more memory pages is not possible)