Kernel Hardening: Protect Linux user accounts against brute force attacks

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.