8 ms·

Kernel Hardening: Protect Linux user accounts against brute force attacks

153 points by CHEF-KOCH 3y ago

CHEF-KOCH 3y ago
The title is actually shortened, the project offers much more, make sure you read the Readme.
fsflover 3y ago
I prefer to rely on Qubes OS for a reasonable security.
- quarterdime 3y ago
  If you are using qubes, you are likely using kicksecure. Whonix (used by many qubes users) is based on kicksecure.
  - fsflover 3y ago
    It's true, however the main security measure of Qubes-Whonix is not Kicksecure but hardware virtualization, which isolates Tor Browser (anon-whonix) from VM establishing the Tor connection (sys-whonix). Kicksecure is of secondary importance.
josephcsible 3y ago
> 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
- 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.
sedatk 3y ago
[flagged]
- deleted 3y ago
  [deleted]
saagarjha 3y ago
I generally dislike such lists because nobody goes through them and analyzes which ones work and which things just seem like they improve security without doing anything at all.
Modified3019 3y ago
Is there some sort of way to to keep a browser profile inaccessible to anything run by the user that isn't the browser, while still having the browser itself being usable by the user?
- fbdab103 3y ago
  QubesOS? I would love to know the answer, but I think it is going to be a long time before we have proper application sandboxing on Linux. The browser is likely the biggest threat vector running on my machine, yet there are no easy ways to lock it down to just reading/writing Downloads and its own cache.
  - bombcar 3y ago
    That's part of the problem, but remember your browser has all your cookies and such - the sites that keep you logged in even when you close the window (like email). So if anything else can read the browser's data, it can get that.
  - hwbunny 3y ago
    AppArmor is fairly easy.
- yjftsjthsd-h 3y ago
  Sure; take your pick: Firejail, flatpak/bubblewrap/bubblejail, docker/podman.
- Timber-6539 3y ago
  You can run Firefox in a docker container. Not sure how much GPU performance you can squeeze out of it but it's doable.
  - mnahkies 3y ago
    You can (allow) access to GPU for cuda applications in docker containers, so I'd be surprised if it wasn't possible to get video acceleration to work normally
efitz 3y ago
This list is pretty awesome and the work is impressive. I wonder what percentage of applications break or have such slow performance that they become unusable, when this set of mitigations is enabled.
Foxboron 3y ago
Parts of this seems dated. I'm pretty sure the entropy changes suggested doesn't really add anything after the recent (~2 years ago) rework of `/dev/random` in the kernel. It doesn't mention `systemd-homed` which might be useful in some cases and the kernel module signing portion is just... wrong or misguided.
rsbac1 3y ago
[dead]

153 points by CHEF-KOCH 3y ago

CHEF-KOCH 3y ago

The title is actually shortened, the project offers much more, make sure you read the Readme.

fsflover 3y ago

I prefer to rely on Qubes OS for a reasonable security.

quarterdime 3y ago
If you are using qubes, you are likely using kicksecure. Whonix (used by many qubes users) is based on kicksecure.
- fsflover 3y ago
  It's true, however the main security measure of Qubes-Whonix is not Kicksecure but hardware virtualization, which isolates Tor Browser (anon-whonix) from VM establishing the Tor connection (sys-whonix). Kicksecure is of secondary importance.

josephcsible 3y ago

> 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
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.

sedatk 3y ago

[flagged]

deleted 3y ago
[deleted]

saagarjha 3y ago

I generally dislike such lists because nobody goes through them and analyzes which ones work and which things just seem like they improve security without doing anything at all.

Modified3019 3y ago

Is there some sort of way to to keep a browser profile inaccessible to anything run by the user that isn't the browser, while still having the browser itself being usable by the user?

fbdab103 3y ago
QubesOS? I would love to know the answer, but I think it is going to be a long time before we have proper application sandboxing on Linux. The browser is likely the biggest threat vector running on my machine, yet there are no easy ways to lock it down to just reading/writing Downloads and its own cache.
- bombcar 3y ago
  That's part of the problem, but remember your browser has all your cookies and such - the sites that keep you logged in even when you close the window (like email). So if anything else can read the browser's data, it can get that.
- hwbunny 3y ago
  AppArmor is fairly easy.
yjftsjthsd-h 3y ago
Sure; take your pick: Firejail, flatpak/bubblewrap/bubblejail, docker/podman.
Timber-6539 3y ago
You can run Firefox in a docker container. Not sure how much GPU performance you can squeeze out of it but it's doable.
- mnahkies 3y ago
  You can (allow) access to GPU for cuda applications in docker containers, so I'd be surprised if it wasn't possible to get video acceleration to work normally

efitz 3y ago

This list is pretty awesome and the work is impressive. I wonder what percentage of applications break or have such slow performance that they become unusable, when this set of mitigations is enabled.

Foxboron 3y ago

Parts of this seems dated. I'm pretty sure the entropy changes suggested doesn't really add anything after the recent (~2 years ago) rework of `/dev/random` in the kernel. It doesn't mention `systemd-homed` which might be useful in some cases and the kernel module signing portion is just... wrong or misguided.

rsbac1 3y ago

[dead]