Oh, if you are also running Crowdstrike on linux, here are some things we identified that you _can_ do:
- Make sure you're running in user mode (eBPF) instead of kernel mode (kernel module), since it has less ability to crash the kernel. This became the default in the latest versions and they say it now offers equivalent protection.
- If your enterprise allows, you can have a test fleet running version n and the main fleet run n-1.
- Make sure you know in advance who to cc on a support ticket so Crowdstrike pays attention.
I know some of this sounds obvious, but it's easy to screw up organizationally when EDR software is used by centralized CISOs to try to manage distributed enterprise risk -- like, how do you detect intrusions early in a big organization with lots of people running servers for lots of reasons? There's real reasons Crowdstrike is appealing in that situation. But if you're the sysadmin getting "make sure to run this thing on your 10 boxes out of our 10,000" or whatever, then you're the one who cares about uptime and you need to advocate a bit.
I would wager that even most software developers who understand the difference between kernel and user mode aren't going to be aware there is a "third" address space, which is essentially a highly-restricted and verified byte code virtual machine that runs with limited read-only access to kernel memory
Not that it changes your point, and I could be wrong, but I'm pretty sure eBPF bytecode is typically compiled to native code by the kernel and runs in kernel mode with full privileges. Its safety properties entirely depend on the verifier not having bugs.
fwiw there's like a billion devices out there with cpus that can run java byte code directly - it's hardly experimental. for example, Jazelle for ARM was very widely deployed
Depending on what kernel I'm running, CrowdStrike Falcon's eBPF will fail to compile and execute, then fail to fall back to their janky kernel driver, then inform IT that I'm out of compliance. Even LTS kernels in their support matrix sometimes do this to me. I'm thoroughly unimpressed with their code quality.
JackC mentioned in the parent comment that they work for a civic tech lab, and their profile suggests they’re affiliated with a high-profile academic institution. It’s not my place to link directly, but a quick Google suggests they do some very cool, very pro-social work, the kind of largely thankless work that people don’t get into for the money.
Perhaps such organizations attract civic-minded people who, after struggling to figure out how to make the product work in their own ecosystem, generously offer high-level advice to their peers who might be similarly struggling.
It feels a little mean-spirited to characterize that well-meaning act of offering advice as “insane.”
- Make sure you're running in user mode (eBPF) instead of kernel mode (kernel module), since it has less ability to crash the kernel. This became the default in the latest versions and they say it now offers equivalent protection.
- If your enterprise allows, you can have a test fleet running version n and the main fleet run n-1.
- Make sure you know in advance who to cc on a support ticket so Crowdstrike pays attention.
I know some of this sounds obvious, but it's easy to screw up organizationally when EDR software is used by centralized CISOs to try to manage distributed enterprise risk -- like, how do you detect intrusions early in a big organization with lots of people running servers for lots of reasons? There's real reasons Crowdstrike is appealing in that situation. But if you're the sysadmin getting "make sure to run this thing on your 10 boxes out of our 10,000" or whatever, then you're the one who cares about uptime and you need to advocate a bit.