Kernel Hardening: Protect Linux user accounts against brute force attacks

Original Article ↗ Hacker News Discussion ↗

A Linux hardening project aimed at blocking brute-force account attacks and tightening kernel controls has reignited debate over how far systems should go in restricting root access and features like kexec or unsigned kernel modules. Supporters see these measures, along with SELinux policies and module signing, as essential defense-in-depth on modern machines, while critics worry about “boiling the frog” toward DRM-like lock‑downs that undermine user control and usability. Related concerns include how best to sandbox browsers and applications, how practical secure configurations are in everyday use, and whether some of the recommended tweaks are outdated or marginal in benefit.

Scope of the Project and Relation to Qubes/Kicksecure

  • Commenters note the title is misleadingly narrow; the project offers broader hardening beyond brute-force protection.
  • In Qubes OS, many users indirectly use Kicksecure via Whonix, but some argue Qubes’ main protection is hardware virtualization, with Kicksecure being secondary.

Kexec, Root, and Defense-in-Depth

  • Some argue disabling kexec is pointless because only root can use it, and limiting root is akin to creeping DRM.
  • Others see value in disabling kexec as one layer in defense-in-depth, especially in combination with SELinux, limited /dev/mem//dev/kmem, disabled /proc/kcore, and module restrictions.
  • Counterpoint: truly preventing root from re-enabling kexec or patching the kernel requires extensive MAC policies and compile-time choices; otherwise root can still modify kernel memory.

Secure Boot, Signed Modules, and User Freedom

  • One side supports only allowing signed kernel modules (optionally, via secure boot) for stronger integrity.
  • Critics worry this evolves into non-optional lockdown (Android, TPM, gaming anti-cheat examples) and undermines user control over their own hardware.
  • Some note hardened setups disable module loading after boot; others object that preventing users from loading their own ring 0 code is unacceptable.

Role of Root, sudo, and suid

  • A strong minority argues the existence and broad power of root is “bad security” and should be minimized or split into narrower roles (network-admin, software-install, etc.).
  • Proposed model: remove or neuter root, avoid suid binaries, and use privileged services or capabilities-based binaries instead.
  • Pushback: administrators must be able to fully control their systems; turning Linux into iOS-like locked-down systems is widely rejected.
  • Some suggest carefully configured sudo plus SELinux already achieves fine-grained control without removing root.

SELinux: Power vs Usability

  • SELinux is cited as a mature way to restrict even root (e.g., blocking module load, kexec).
  • Opinions split: some say it works well in practice; others see it as complex, poorly documented, and something people mainly try to “get out of the way.”

Browser Sandboxing and Application Isolation

  • Multiple approaches discussed: separate user accounts, AppArmor, Firejail, flatpak/bubblewrap, containers (docker/podman), Qubes-style VMs, or remote browsers.
  • Consensus: many tools exist to protect the system from the browser; fully protecting the browser’s data from other user processes is harder without system-wide sandboxing.