[HN Gopher] Kernel Hardening - Protect Linux User Accounts Again...
       ___________________________________________________________________
        
       Kernel Hardening - Protect Linux User Accounts Against Brute Force
       Attacks
        
       Author : CHEF-KOCH
       Score  : 27 points
       Date   : 2024-03-10 17:46 UTC (5 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | CHEF-KOCH wrote:
       | The title is actually shortened, the project offers much more,
       | make sure you read the Readme.
        
       | fsflover wrote:
       | I prefer to rely on Qubes OS for a reasonable security.
        
         | quarterdime wrote:
         | If you are using qubes, you are likely using kicksecure. Whonix
         | (used by many qubes users) is based on kicksecure.
        
           | fsflover wrote:
           | 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 wrote:
       | > 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 wrote:
         | 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 wrote:
           | 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 wrote:
             | 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.
        
       ___________________________________________________________________
       (page generated 2024-03-10 23:00 UTC)