Because it isn’t. Their Linux sensor also uses a kernel driver, which means they could have just as easily caused a looping kernel panic on every Linux device it’s installed on.
Also, it’s less about “their” drivers and more about what a kernel module can do.
Saying “there’s no way to know” doesn’t fit, because we do know that a malformed kernel module can destabilize a linux or mac system.
“Malformed file” isn’t a programming defect or something you can fix by having a better API.
Security operations being one of the things that is often best done at the kernel level because of the need to monitor network and file operations in a way you can’t in user mode.
Because it isn’t. Their Linux sensor also uses a kernel driver, which means they could have just as easily caused a looping kernel panic on every Linux device it’s installed on.
There’s no way of knowing that, though. Perhaps their Linux and Darwin drivers wouldn’t have paniced the system?
Regardless, doing almost anything at the kernel level is never a good idea
It’s not impossible. Crowdstrike has done it recently to linux machines.
Kernel panic observed after booting 5.14.0-427.13.1.el9_4.x86_64 by falcon-sensor process:
https://access.redhat.com/solutions/7068083
Also, it’s less about “their” drivers and more about what a kernel module can do.
Saying “there’s no way to know” doesn’t fit, because we do know that a malformed kernel module can destabilize a linux or mac system.
“Malformed file” isn’t a programming defect or something you can fix by having a better API.
Security operations being one of the things that is often best done at the kernel level because of the need to monitor network and file operations in a way you can’t in user mode.