直接剥离root冗余特权是精准授权而非降权：通过capability机制仅赋予服务必需的内核级权限，如web服务只需cap_net_bind_service，禁用cap_sys_admin等高危能力，并结合systemd的capabilityboundingset、protectsystem、readonlypaths等配置实现纵深防御。
直接剥离 root 身份中的冗余特权，不是“降权”而是“精准授权”。核心思路是：让服务以普通用户身份启动，再通过 capability 机制仅赋予它真正需要的那几项内核级权限，其他一概不给。这比用 root 启动后再禁用某些能力更安全、更可控。
明确服务实际需要的能力
先别急着加能力，得弄清它到底要做什么。比如：
- Web 服务监听 80/443 端口 → 只需 CAP_NET_BIND_SERVICE
- 网络诊断工具发原始包（如 ping、tcpdump）→ 需要 CAP_NET_RAW，部分还涉及 CAP_NET_ADMIN
- 日志服务写入 /dev/log → 需要 CAP_SYSLOG
- 服务要挂载临时文件系统（极少见）→ 才考虑 CAP_SYS_ADMIN，但务必评估替代方案
多数服务根本不需要 CAP_SYS_ADMIN、CAP_DAC_OVERRIDE、CAP_SYS_MODULE 这类高危能力。宁可服务启动失败，也不要盲目保留。
用 setcap 给二进制文件授予权限
这是最常用、最轻量的方式，适用于已编译完成的可执行文件：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 给 nginx 添加绑定低端口能力：sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx
- 验证是否生效：getcap /usr/sbin/nginx 应输出 /usr/sbin/nginx cap_net_bind_service=ep
- 确保该文件没有 setuid/setgid 位（ls -l /usr/sbin/nginx 中不应出现 s），否则 capability 会被内核忽略
- 注意：setcap 只对真实二进制有效，对 shell 脚本、符号链接无效；脚本需改用 systemd 或 wrapper 封装
在 systemd 服务中精细管控能力集
现代 Linux 发行版推荐用 systemd 单元文件统一管理，比 setcap 更灵活、更可审计：
- 禁用所有默认能力，只留必需项：CapabilityBoundingSet=~CAP_SYS_ADMIN CAP_SYS_MODULE CAP_SYS_PTRACE
- 显式授予绑定端口能力：AmbientCapabilities=CAP_NET_BIND_SERVICE
- 限制文件系统可见性：ProtectHome=true、ProtectSystem=full、ReadOnlyPaths=/etc /usr
- 关闭 SUID/SGID 提权可能：RestrictSUIDSGID=true
这样即使二进制本身没设 capability，systemd 也会在启动时按配置初始化进程的能力集，且能与 Seccomp、Namespaces 深度协同。
配合路径与资源限制，堵住能力之外的漏洞面
Capability 解决的是“能不能做”，但不解决“能不能读到不该读的”或“能不能耗尽资源”。必须同步收紧：
- 用 ReadOnlyPaths 和 Protect* 选项锁定敏感路径（如 /root、/home、/boot）
- 显式声明可读写目录：ReadWritePaths=/var/log/myapp /var/cache/myapp，其余默认只读甚至不可见
- 对网络服务，结合 RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 屏蔽不必要的协议族
- 必要时启用 seccomp-bpf 过滤系统调用，例如禁止 open_by_handle_at、pivot_root 等高风险调用
能力只是最小权限的一环，脱离上下文限制的能力仍是风险源。
