@yura>Can Microsoft block this access level? No, because they are obliged to allow it via the EU court
They in fact wanted to do this some time ago and EU blocked it. They proposed a security API that would give more access into the inner workings of the kernel, but EU considered it anti-competitive because of a possibility that smaller companies wouldn't have access to the API.
>As far as I understand Windows have some default fixing mechanisms that couldn't work because of faulty driver working on early boot process causing endless reboots.
The typical self-repair mechanisms would prevent all of this if Crowdstrike didn't label their driver as a boot-start driver that must always be loaded when starting Windows.
>So, could similar things happen under linux. Well, it would be unfair to say what could have happened because it happened already before
RHEL was also affected a month or so later after a kernel update. They have a history of issuing broken updates or their software breaking systems.
>But do you really ask people to manually test every virus database update before applying it in the company?
Yes, this should be absolutely expected. In an enterprise environment, no update that wasn't tested should be applied on production systems. It's an industry standart to partially roll out updates in enterprise usually in a N, N-1 and N-2 fashion (N being the newest version.)
The version N should only be installed on test systems that do nothing but test new updates and the updates should be installed automatically as they come out. This stage is usually called test. The next stage is staging where N-1 versions are installed, these are approved manually and run on non-critical systems where outages are only annoying to deal with. The last stage is production where N-2 versions live and they are also manually approved. At this point everything should have been tested at least for few days, ideally a week or two and everything should be fine.
Now the problem is that the Crowdstrike software allows this kind of granular control over updates, but some updates are allowed to bypass these policies completely and this was one of them. This turned out to be the issue I described in my first post about this as the "seemingly updates faster than updating the policy that disables auto-updates".
Consider parts of the post I left out as something I fully agree with.