6 ms·

> Kexec is disabled as it can be used to load a malicious kernel and gain arbitrary code execution in kernel mode. Only root can kexec anyway. "Hardening" guid

> Kexec is disabled as it can be used to load a malicious kernel and gain arbitrary code execution in kernel mode. Only root can kexec anyway. "Hardening" guidance that suggests limiting the root user feels like an attempt to boil the frog of widespread Linux DRM.

nimbius 3y ago
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.
- Borealid 3y ago
  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?
olliej 3y ago
This sounds like it’s doing something similar to system integrity protection on mac+iOS where the security model is “root cannot write to kernel memory”. Because otherwise all you have to do is get root access to control a system, which is pretty easy given that getting root generally just means tricking the user into entering their password (because they’re generally in the sudoers group), or spying on other user processes (like xterm or whatever). Gaining root on a normal user machine is not hard if that’s your goal, and given a security model that depends entirely on not getting root it’s the obvious first step.
- josephcsible 3y ago
  This reminds me of https://xkcd.com/1200/ https://xkcd.com/1200/ - what would someone who gets into a normal user machine like that care about kernel access for? This type of "protection" feels like it only hurts legitimate users without even slightly inconveniencing actual bad guys.
  - exe34 3y ago
    It's to prevent the user from dumping the DRM keys.
  - Karellen 3y ago
    Even on a single-user system, if an attacker can't elevate to root then at least you don't have to reinstall the whole computer from scratch. You can just wipe the home directory, log in to a fresh account, and start putting your digital life back together. If they get root, you can't trust anything on the system any more. You have to do 10x the work just to get to the point of having a system you can even start to use. (Do you have a bootable install ISO handy anywhere? Is it current?)
    - mschuster91 3y ago
      > If they get root, you can't trust anything on the system any more. ... and that includes the firmware of all components involved.
    - 3y ago
charcircuit 3y ago
The existence of the root user is bad security. Any distro serious about security should disable it and strip it of as much power as possible. It is such a juicy target for attackers due to how much power it has and most distros protect it poorly by having programs such as sudo installed allowing an attacker to easily escalate their privileges.
- josephcsible 3y ago
  How do you propose that the owner of a system should be able to administer it?
  - charcircuit 3y ago
    The distro maintainers should make sure the operating system works well on its own. For what needs to be customized there can be a settings application and individual applications can expose ways for themselves to be customized.
    - josephcsible 3y ago
      You want distro maintainers to have final control instead of hardware owners? Isn't that arguing for the iOS-ification of Linux?
      - charcircuit 3y ago
        I want distros to make an operating system that actually works and doesn't need to be fiddled with. Hardware owners shouldn't have to be the ones fixing the operating system. Most people just want their computer to work and don't want to learn about the internals of how it works. If a user really cares about changing the internals he can make his own operating system. >Isn't that arguing for the iOS-ification of Linux? Linux distros could learn a thing or two (or 100) from how iOS handles security.
        josephcsible 3y ago
viraptor 3y ago
The intention is for it to be accessible by root only. But if you get a situation where either that check fails, or you can convince some root process to kexec without further checks, you have a problem. If you know you're not using kexec, you can get rid of that whole issue.

nimbius 3y ago

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.

Borealid 3y ago
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?

olliej 3y ago

This sounds like it’s doing something similar to system integrity protection on mac+iOS where the security model is “root cannot write to kernel memory”. Because otherwise all you have to do is get root access to control a system, which is pretty easy given that getting root generally just means tricking the user into entering their password (because they’re generally in the sudoers group), or spying on other user processes (like xterm or whatever). Gaining root on a normal user machine is not hard if that’s your goal, and given a security model that depends entirely on not getting root it’s the obvious first step.

josephcsible 3y ago
This reminds me of https://xkcd.com/1200/ https://xkcd.com/1200/ - what would someone who gets into a normal user machine like that care about kernel access for? This type of "protection" feels like it only hurts legitimate users without even slightly inconveniencing actual bad guys.
- exe34 3y ago
  It's to prevent the user from dumping the DRM keys.
- Karellen 3y ago
  Even on a single-user system, if an attacker can't elevate to root then at least you don't have to reinstall the whole computer from scratch. You can just wipe the home directory, log in to a fresh account, and start putting your digital life back together. If they get root, you can't trust anything on the system any more. You have to do 10x the work just to get to the point of having a system you can even start to use. (Do you have a bootable install ISO handy anywhere? Is it current?)
  - mschuster91 3y ago
    > If they get root, you can't trust anything on the system any more. ... and that includes the firmware of all components involved.
  - 3y ago

charcircuit 3y ago

The existence of the root user is bad security. Any distro serious about security should disable it and strip it of as much power as possible. It is such a juicy target for attackers due to how much power it has and most distros protect it poorly by having programs such as sudo installed allowing an attacker to easily escalate their privileges.

josephcsible 3y ago
How do you propose that the owner of a system should be able to administer it?
- charcircuit 3y ago
  The distro maintainers should make sure the operating system works well on its own. For what needs to be customized there can be a settings application and individual applications can expose ways for themselves to be customized.
  - josephcsible 3y ago
    You want distro maintainers to have final control instead of hardware owners? Isn't that arguing for the iOS-ification of Linux?
    - charcircuit 3y ago
      I want distros to make an operating system that actually works and doesn't need to be fiddled with. Hardware owners shouldn't have to be the ones fixing the operating system. Most people just want their computer to work and don't want to learn about the internals of how it works. If a user really cares about changing the internals he can make his own operating system. >Isn't that arguing for the iOS-ification of Linux? Linux distros could learn a thing or two (or 100) from how iOS handles security.
      - josephcsible 3y ago

viraptor 3y ago

The intention is for it to be accessible by root only. But if you get a situation where either that check fails, or you can convince some root process to kexec without further checks, you have a problem. If you know you're not using kexec, you can get rid of that whole issue.