You seem knowledgable. I’m surprised that it’s even possible for a software vendor to inject code into the kernel. Why is that necessary?
The kernel is responsible for managing hardware and general low-level system operations. Anything that wants to do those things needs to get itself into kernel mode one way or another.
The typical way you do this is called a “driver” and no one thinks about them as being kernel code. Things like graphics cards and the like.
Things that want to do actions like monitor network traffic or filesystem activity system wide or in a lower level capacity than the normal tools provide also need to be kernel level.
In a security context, that specifically would include things that want to monitor raw packets rather than the parsed content that assumes the packet is well formed in a way that a malicious one might not be.
Cloudstrike does the same thing on Linux, and the typical tools for network management or advanced security are also either compiled in or loadable kernel modules.
It’s easy to forget that ip/ebtables and selinux and friends are kernel level software frequently distributed as kernel modules, in the case of the firewalls, or compiled in with a special framework and not just user mode software.
TL;DR: Because the underlying OS is garbage.
Whatever CrowdStrike’s “features” are should already be core security features of the kernel itself, or be exposed/extracted into user space.
NT was supposed to be a micro kernel. That this tool injects itself into the kernel immediately compromises the kernel. Edit: I should point out that it seems that CS injects drivers into the Linux kernel too, it might just be that Linux handles a driver crash more elegantly.
No different to the gaming anti-cheat kernel crap.
Having a “security” tool immediately compromise your actual security is absurd.
I, too, work in a similar type of company, and can confirm from experience that Linux can get just as absolutely fucked up by a bad kernel module as windows.
And it’s not just changes to the module that can cause things to go wrong.
For example, the kernel released alongside the latest Ubuntu LTS included a change that conflicted with our module behaviour, so machines with that kernel or newer would panic on boot.
It was a super minor change, but when you’re deep in the weeds, it’s really easy for these things to be brittle. But that’s just an inherent consequence of the fact that this sort of stuff is intrinsically low-level interaction with the OS itself.
I’d love to know how you plan to do user mode packet filtering. Keep in mind that on Linux, the designated API is inherently kernel mode. https://netfilter.org/
This isn’t one of the cases where we’re talking about Linux being superior to windows. Any OS will be fucked if you give it a mangled kernel module. In this case, it’s just that only one got one.
Your perception that anything that touches the kernel is an intrinsic security risk is unfounded.
Not who you asked, but did you ever hear of Valiant and their kernel level anti cheat.
This is not a 1:1 comparison but anticheat software running in the kernel has the ability to monitor all other processes due to its permission levels. It can monitor all scheduled tasks and infer from that information.
Drivers need similar access but for different reasons, they need access to os functionality a user would absolutely never be granted. This is because they interface directly with hardware and means when drivers crash, they generally don’t do it gracefully. Hence the BSOD loop and the need for booting windows without drivers (i.e. safe mode) and the deletion of the misconfiguration file.
