Hacker News Reader

Comment by nimbius | Hacker News Reader

Disabling kexec would prevent unauthorized operation in the event of a zero-day root compromise. It would require a reboot to re-enable, which should generate a security event in a SIEM or central monitoring for unauthorized change in operating state.

View on HN

How would it require a reboot to re-enable? The root user can write directly to kernel memory by a number of means, patching the kernel live to re-enable kexec.

Closing those holes requires using a pretty extensive MAC policy restricting root in all sorts of ways.

True, its assumed you'd also be running selinux with contexed users as well. So far the only players that care to publish contexts for the OS are doing so as part of DoD postures for security relevant objects in a stig.

Disabling kexec still feels relevant though as part of a defense in depth approach to stop threat actors that aren't state sponsored (eg, metasploit folk)

Other tools like aide may help detect the event as well. Fapolicyd could also help this effort.

Closing all means for root to access kernel memory is part of hardening. Modern mainstream distros don’t expose /dev/kmem and /dev/mem can be limited to less dangerous pages like MMIO, /proc/kcore can be disabled, to, etc. It goes beyond MAC policies, some functionality is just omitted from the kernel via compile-time config.

But... root can load kernel modules, and kernel modules can write to arbitrary kernel memory, no?

You usually can't run unsigned kernel modules if you have EFI secure boot turned on, depending on the way your distribution's kernel is configured.

Right but then we're back to the "it's not my computer any more" problem. Disallowing me from running my own ring 0 code on my own computer isn't an acceptable trade-off.

You can opt in or opt out as you wish. You get to decide whether the added security of only allowing signed kernel modules is the right trade-off for you. Am I missing something here?

In cases where you can genuinely just flip a switch and get back proper access to the machine I don't mind it that much, but these "we must restrict the user for 'security' reasons" things usually don't stay like that forever.

But this is Linux so you can use a different distribution if your current distro is daft like that.

Or do you mean that certain programs (like one mentioned by sibling) require the switch to be on?

Yeah, that's one of the ways these "optional" "security measures" often become non-optional. Android is a prime example of a system where this has already happened: sure, you can root your device (if your manufacturer allows you to), but none of the software you need.

Another way is simply for the manufacturer to lock down the bootloader/BIOS and not let you disable "secure" boot, as is also common in the Android world.

That's what everyone said about TPM and Secure Boot, and now you can't, e.g., play Valorant without enabling both.

If it’s me who disallowed “future me” (or someone pretending to be future me because my account was compromised) loading unsigned modules, I don’t see it as a problem.

Typically 'hardened' builds disable loading kernel modules shortly after boot. Compromising root at some point after this point doesn't guarantee the ability to load additional kernel modules.

Reply on news.ycombinator.com