Of course something like an EDR requires kernel level access otherwise it's too easy to bypass. But Apple has system extensions as a useful compromise. They're basically kernel level APIs that can be called by validated signed software. I think it's a good alternative to just allowing random code to run in the kernel.
The thing is, Apple has a habit of going to software vendors and saying: "We're changing this next year. There'll be a 2 year deprecation period and after that we'll lock you out. So change up or die off. We don't care."
Microsoft doesn't really do this and even if they do there's a lot of ifs and buts. They're much more receptive to the concerns of legacy software vendors because they represent a much bigger share of their market and the customer base (enterprise market) that cares about legacy is also very big and vocal.
Needless to say this is also the customer base that got heavily hammered by what happened today. But nobody thinks about that until it actually happens.
OS X was using Unix back then as well, and the foundational design didn’t save it. But like you mention, Apple does more to protect the underlying system today than they did back then. I can’t even remember the last kernel panic I had. They used to be a semi-regular occurrence.
IIRC OS X, and MacOS, are and have been certified UNIX for 20ish years.
https://arstechnica.com/information-technology/2006/10/7998/
It absolutely would. Windows is way ahead in terms of driver isolation and stability. Most drivers cannot bring down the system (your GPU driver can crash, your screen will flicker and maybe apps that were using it will crash, but the system recovers). Not so on Linux unfortunately, any driver will bring the system down.
More recently certain class of drivers have been making use of ebpf or virt2, which helps in isolating the driver. But I know for a fact that CS on Linux is as low level as it can be.
So long story short only MacOS is resistant to this, because they've simply deprecated any third party kernel extensions/modules.
Only if the userspace part of the driver has crashed. It's not really relevant to what happened here (it was kernel code).
I work for a company that provides secure endpoints that are Linux based (and can also run Windows apps without issue). We do not ship Linux kernels that contain drivers that cause crashes.
Per our IT patterns and also mandated by our commercial contracts, we investigate any crashes that occur. Over the last five years, not a single crash has been caused by a device driver.
We also will never have a use for the style of security software that Crowdstrike has. Our security stack is proactively preventative, not reactive or looking for "anomalies".
So this "it absolutely would [happen on Linux]", should have an asterisk, a huge one glaring like the sun, and without said asterisk is inaccurate at an extreme.
But good job on not having a crash from a driver so far. Raspberry Pi users weren’t that lucky for example.
[0]: https://forums.developer.nvidia.com/t/bug-report-455-23-04-k...
git was literally created to develop Linux.
If you're sure you don't want to freely use your machine just because third-party code can be dangerous, then yes, you can blame Microsoft for not taking control away from you.
MS provided a kernel-level entry point that other OSes didn't need.
MS have an aggressive auto-update policy that is anti-best practise.
MS have a signed binary agreement that doesn't catch the things it is meant to.
You absolutely do. Otherwise, you'll be unable to detect malware that IS putting itself into the kernel.
https://news.ycombinator.com/item?id=41009740
Such a file will not have the right signature and checksum to be considered a valid executable. Either these were not checked, or whatever was doing the checking responded poorly and left the system in a state that's difficult to recover.
Windows is the platform, CrowdStrike makes a product on this platform and their users willingly install, accept all the security prompts and use it. Short of Apple-style locking users out of their own devices, there is little they can do here.
I'm not well-versed in Windows enough to be able to tell if they provide better ways and safe APIs to achieve what CrowdStrike does, but even if they did, there is no telling if CrowdStrike or anyone else would use that or not.
> but I feel that good OS should prevent a 3rd party app to cause such damage
It does? It also allows the owner of the machine to bypass those preventions, which is what CrowdStrike seem to require for their product to function.
I think the "OS should protect me from myself" is a very iPad-style expectation from computers. Personally I'm happy there are OSes that don't work this way.
> Would it happen on Linux?
$ modprobe crap-mod
I guess it would.
On Windows, software regularly mucks around in the kernel (device drivers, system level tools like wireshark, etc), therefore it is also necessary for security software like CrowdStrike to also muck in the kernel so it can monitor what all the other kernel level software is doing. As demonstrated today, anything that mucks in the kernel runs the risk of crashing the kernel.
In Linux, software doesn't even get that option. Nothing ever gets kernel access except the kernel itself. Root is not kernel access. The kernel still decides what root is able to do. Drivers that require that access are built into the kernel. Software that requires deeper access like Wireshark tells the kernel what to do (through system calls as root) and the kernel does it on that programs behalf. Therefore, the kernel knows everything that any program does on the system. With a trustworthy kernel, all that security software must do is instruct the kernel to monitor activity on it's behalf.
worth noting Microsoft had a solution a few years ago that would of prevented this issue from happening, Windows 10X, due to atomic updates.
> In Linux, software doesn't even get that option. Nothing ever gets kernel access except the kernel itself. Root is not kernel access.
root has kernel access, even if the kernel restricted it, it can write to the disk and change the boot process.
also worth nothing that a popular form of software distribution on Linux is curl http://randomscript.sh | sudo sh which is arguably worse than anything on Windows.
Root has access to the kernel but the kernel knows everything that happens and that's my point. The kernel won't stop you from compiling a new kernel and setting it to run at the next boot. However, CrowdStrike running on Linux with eBPF for example would be able to identify and prevent such tampering without truly being in the kernel itself.
The most common way to install software on Linux is from your trusted distro repositories and from Flathub or the Snap store. Grabbing a script from the internet and piping it to a root shell is bad and something I'm sure we've all done. But take the most installed program on Windows which is likely Chrome, it really doesn't do anything differently. You download a small executable which requests admin, then it proceeds to download Chrome and install it. I'd argue grabbing a script might be the safer option because unlike installer executables from the internet, you at least have the option to read the script before running it if you choose.
what about loadable kernel modules?
Yes all platforms seen bad days and have their own issues.
But windows is different - most of its troubles come from human factor - low quality people making (or made 10 years ago) low quality decisions and every new iteration is just another layer of bad decisions aimed to cover the holes in previous layer.
You can see and feel it even un ui - there is no esthetics nor real usability and never was.
Overall windows ux is not even close to what apple have invested in their ecosystem. It’s not even apple to oranges comparison.
Even if there are few nice and handy features here and there.
Then you understand that it is not the core that crashed, but if there is any error, in any driver, the mandated behavior is to trigger a "BUGCHECK" in the same way that you would just do a printf(error) usually...
Windows is closed source for the vast majority of people who use it. No one oustide Microsoft, not even those who may have signed NDAs and can read some of the code, is free to edit the Windows source and recompile. If a Windows user wants to prevent something like this outage from happening, he cannot obtain the Windows source and make changes to prevent it. Instead he is encouraged (perhaps compelled) to let Microsoft remotely install and run new code any time it wants.
needs better safeguards.
