4 ms·

Think more, imagine that the your CrowdStrike security layer detects an 'unexpected' kernel level data file. Choice #1 Diable security software and continue. C

• derefr 2y ago
  Choice #3 structure the update code so that verifying the integrity of the update (in kernel mode!) is upstream of installing the update / removing the previous definitions package, such that a failed update (for whatever reason) results in the definitions remaining in their existing pre-update state. (This is exactly how CPU microcode updates work — the CPU “takes receipt” of the new microcode package, and integrity-verifies it internally, before starting to do anything involving updating.)
  • warkdarrior 2y ago
    > a failed update (for whatever reason) results in the definitions remaining in their existing pre-update state Fantastic solution! You just gave the attackers a way to stop all security updates to the system.
    • monocasa 2y ago
      When you can't verify an update, rolling back atomically to the previous state is generally considered the safest option. Best run what you can verify was a complete package from whoever you trust.
    • JohnBooty 2y ago
      No, that doesn't follow. For most systems, a sensible algorithm would be "keep running the last known good definition, until we get the next known good definition" In other words: ignore bad updates but keep checking for valid ones. That doesn't mean you've permanently lost the ability to update. Of course, for some systems, different behavior might make more sense.