内核加固：保护 Linux 用户账户免受暴力破解攻击

项目范围及与 Qubes/Kicksecure 的关系

• 评论者指出标题的范围有误导性地狭窄；该项目提供的不只是防暴力破解，还包括更广泛的加固。
• 在 Qubes OS 中，许多用户通过 Whonix 间接使用 Kicksecure，但有人认为 Qubes 的主要保护来自硬件虚拟化，而 Kicksecure 只是次要的。

Kexec、Root 与纵深防御

• 有人认为禁用 kexec 没什么意义，因为只有 root 才能使用它，而限制 root 有点像逐步引入 DRM。
• 也有人认为禁用 kexec 有价值，它是纵深防御中的一层，尤其是与 SELinux、受限的 /dev/mem//dev/kmem、禁用 /proc/kcore 以及模块限制结合使用时。
• 反驳观点：要真正阻止 root 重新启用 kexec 或修补内核，需要大量的 MAC 策略和编译期选择；否则 root 仍然可以修改内核内存。

Secure Boot、签名模块与用户自由

• 一方支持只允许签名的内核模块（可选地通过 secure boot）以获得更强的完整性。
• 批评者担心这会演变成非可选的锁定（如 Android、TPM、游戏反作弊的例子），并削弱用户对自己硬件的控制。
• 有人指出，加固后的系统在启动后会禁用模块加载；但也有人反对，认为阻止用户加载自己的 ring 0 代码是不可接受的。

Root、sudo 与 suid 的角色

• 一个强势少数派认为 root 的存在及其广泛权限是“糟糕的安全设计”，应尽量减少或拆分为更细的角色（网络管理员、软件安装等）。
• 建议的模型是：移除或弱化 root，避免 suid 二进制文件，改用特权服务或基于 capability 的二进制文件。
• 反对意见：管理员必须能够完全控制自己的系统；把 Linux 变成类似 iOS 的锁定系统，普遍不被接受。
• 也有人建议，配置得当的 sudo 加上 SELinux 已经能在不移除 root 的情况下实现细粒度控制。

SELinux：能力与可用性

• SELinux 被引用为一种成熟的方法，可以限制甚至 root 的行为（例如阻止模块加载、kexec）。
• 观点分歧：有人说它在实践中效果很好；也有人认为它复杂、文档差，而且人们主要只是试图把它“挡在一边”。

浏览器沙箱与应用隔离

• 讨论了多种方法：单独的用户账户、AppArmor、Firejail、flatpak/bubblewrap、容器（docker/podman）、Qubes 风格的虚拟机，或远程浏览器。
• 共识是：有很多工具可以保护系统免受浏览器影响；但在没有系统级沙箱的情况下，要完全保护浏览器数据不被其他用户进程影响则更难。