linux capabilities 是细粒度权限控制机制，可替代 root 全权模式，需按需授予最小必要能力（如 nginx 仅需 cap_net_bind_service），结合 systemd 的 capabilityboundingset、ambientcapabilities 和 nonewprivileges=true 安全配置，并避免误用高危能力。
Linux Capabilities 是一种细粒度的权限控制机制，能替代传统 root 全权模式，让服务仅拥有完成任务所必需的最小特权。合理使用可显著降低因漏洞或配置错误导致的提权风险。
明确哪些 Capability 对服务真正必要
盲目添加 CAP_SYS_ADMIN 或 CAP_NET_ADMIN 等高危能力等于变相放行 root 权限。应先通过 strace 或 auditd 观察服务运行时实际触发的权限拒绝（如 Operation not permitted），再针对性补足。例如：
- Nginx 绑定 80 端口只需 CAP_NET_BIND_SERVICE，无需 CAP_SYS_ADMIN
- 容器运行时（如 runc）可能需要 CAP_SETUIDS、CAP_SETGIDS 和 CAP_SETPCAPS，但应禁用 CAP_SYS_MODULE
- 日志轮转工具 logrotate 若需修改属主，仅需 CAP_CHOWN，而非完整 root
在 systemd 服务中安全启用 CapabilityBoundingSet
systemd 提供 CapabilityBoundingSet 和 Capabilities（即 Ambient/Effective/Inheritable 设置）双层控制。推荐组合使用：
- 用 CapabilityBoundingSet= 严格限制进程可获取的所有能力上限（不可被子进程提升）
- 用 ExecStart= 前加 setcap 或 ambient capability 方式授予具体能力
- 务必设置 NoNewPrivileges=true 阻止 setuid/setgid 二进制绕过 capability 限制
示例（Nginx 服务片段）：
CapabilityBoundingSet=CAP_NET_BIND_SERVICEAmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
避免常见误用与陷阱
Capability 不是万能补丁，错误使用反而削弱安全性：
- CAP_SYS_PTRACE 允许调试任意进程——除非是监控/诊断工具，否则禁止启用
- 不要对脚本解释器（如 /usr/bin/python）直接 setcap，而应封装为专用二进制或用 systemd 的 ExecStartPre= 动态授予权限
- 容器环境（如 Docker）中，--cap-add 应配合 --cap-drop=all 使用，显式声明所需能力
- 内核版本低于 4.14 时，AmbientCapabilities 支持不完善，需降级使用 setcap + user=root 并缩小 UID 范围
验证与持续监控
部署后必须验证能力是否按预期生效且无冗余：
- 用 getpcaps
查看进程当前拥有的有效能力 - 用 capsh --print 在服务上下文中检查 ambient/effective set
- 结合 auditd 规则（如 -a always,exit -F arch=b64 -S capset）记录 capability 修改行为
- 定期扫描 find /usr/bin -type f -perm /6000 -exec getcap {} \;，识别意外 setcap 的二进制
