4 ms·

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.

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.

nimbius 3y ago
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.
ivlad 3y ago
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.
- mort96 3y ago
  But... root can load kernel modules, and kernel modules can write to arbitrary kernel memory, no?
  - noodlesUK 3y ago
    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.
    - mort96 3y ago
      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.
      - nequo 3y ago
        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?
        mort96 3y ago
        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.
        nequo 3y ago
        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?
        mort96 3y ago
        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.
        josephcsible 3y ago
        That's what everyone said about TPM and Secure Boot, and now you can't, e.g., play Valorant without enabling both.
  - Cody-99 3y ago
    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.

nimbius 3y ago

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.

ivlad 3y ago

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.

mort96 3y ago
But... root can load kernel modules, and kernel modules can write to arbitrary kernel memory, no?
- noodlesUK 3y ago
  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.
  - mort96 3y ago
    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.
    - nequo 3y ago
      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?
      - mort96 3y ago
        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.
        nequo 3y ago
        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?
        mort96 3y ago
        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.
      - josephcsible 3y ago
        That's what everyone said about TPM and Secure Boot, and now you can't, e.g., play Valorant without enabling both.
- Cody-99 3y ago
  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.