Linux capabilities 与 SUID 的权限边界

SUID 位与 linux capabilities 常被放在同一张安全清单里，但两者的权限模型并不等价。SUID 位作用于可执行文件，使进程以文件属主的身份运行，属主为 root 时，进程就继承了完整的 root 权限。而 capabilities 将 root 的超级权限拆分为独立单元，例如 CAP_NET_BIND_SERVICE 仅允许进程绑定低端口，CAP_DAC_READ_SEARCH 仅放开文件读取与目录搜索。二者不是同一层级的替代方案，而是两种粒度完全不同的授权机制。

从攻击面角度看，SUID 的粒度粗且难以收敛。一个带 SUID 位的程序一旦存在可利用的漏洞，攻击者获得的往往是完整的 root 上下文，而非单一权限。capabilities 的优势在于可精确到单项能力，理论上能显著缩小提权后的可用面。但实际落地时，这种精细度会带来新的问题：系统组件、脚本或第三方软件对 capabilities 的兼容性并不一致，部分程序在缺少某项能力时表现出的失败方式并不直观，排查成本反而高于 SUID 时代。

判断二者的边界，核心依据是“程序是否真正需要完整 root”。系统级的认证、挂载、密码修改类工具，如 su、sudo、mount、passwd，它们的设计前提就是拥有完整权限，强行替换为 capabilities 只会破坏其行为预期。而自定义开发的、仅需绑定特权端口或读取受限文件的服务进程，才是 capabilities 的正确场景。换句话说，SUID 适合“这个程序本身就是系统信任组件”的情形，capabilities 适合“这个程序只缺某一项权限”的情形。

实际操作中还有一个容易忽略的维度：可审计性。SUID 文件可以用 find 配合包管理器校验快速枚举，非包来源的 SUID 文件很容易被识别为异常。capabilities 则分散在文件系统的扩展属性中，常规的权限审计命令不会覆盖它，需要专门的工具逐一读取。若团队没有建立对应的基线记录，capabilities 的改动可能比 SUID 更难追踪。

回到基线检查的场景，一个务实的判断标准是：优先处理 SUID 清单中非包来源或权限位被改动的文件，这类命中几乎必然意味着异常；capabilities 则先盘点、记录基线，再根据业务进程的实际需求逐个收敛，而不是一次性批量替换。权限收敛的价值在于可验证、可回滚，而不在于把每一项都改到最严格。