systemd服务应显式限定CapabilityBoundingSet、禁用隐式继承、剔除高危能力，并配合NoNewPrivileges和AmbientCapabilities实现最小权限；部署后须验证运行时能力与security评分。
在 systemd 的 .service 单元中收紧 CapabilityBoundingSet，核心是“只放行必需能力、显式剔除高危能力、阻断能力继承”，而不是默认放任。最高安全合规要求不是加功能，而是做减法——让进程哪怕以 root 身份启动，也无法执行超出业务所需的系统调用。
明确限定必要能力，禁用隐式继承
CapabilityBoundingSet 必须显式列出服务真正需要的能力，不能留空或依赖默认值。systemd 默认赋予全部 capabilities（等同于 root 权限），必须主动约束：
- 例如 Web 服务需监听 80/443 端口：写
CapabilityBoundingSet=CAP_NET_BIND_SERVICE - 日志服务需写内核日志：加
CAP_SYSLOG，但不加CAP_SYS_ADMIN - 同时启用
RestrictNamespaces=true和RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6，防止滥用网络协议栈 - 务必配
RestrictCapabilities=true，关闭 capability 的隐式继承机制，避免子进程意外获得父进程未显式授予的能力
显式剔除高危能力，而非仅保留少数
仅写白名单存在遗漏风险，更稳妥的做法是“白名单 + 黑名单双重控制”。用波浪号语法直接排除已知高危项：
CapabilityBoundingSet=~CAP_SYS_ADMIN CAP_SYS_MODULE CAP_SYS_PTRACE CAP_AUDIT_WRITE CAP_SETUID CAP_SETGID CAP_CHOWN CAP_FOWNER- 特别注意
CAP_SYS_PTRACE：生产环境绝不启用，否则攻击者可用ptracedump 内存、注入代码 -
CAP_AUDIT_WRITE可被用于干扰审计日志，应移除 - 若服务不需要切换用户身份，
CAP_SETUID/CAP_SETGID必须剔除
配合 NoNewPrivileges 和 ambient 能力传递
CapabilityBoundingSet 单独配置不够，必须与运行时防护联动：
- 设
NoNewPrivileges=yes，禁止进程后续通过 execve 提升权限（包括 setuid 二进制、capability 继承） - 若需子进程也具备绑定低端口能力，加
AmbientCapabilities=CAP_NET_BIND_SERVICE，确保能力可传递且不依赖特权文件 - 避免使用
setcap直接给二进制赋权——它绕过 systemd 的审计链路和统一管控，违反最小权限原则
验证配置是否生效
部署后必须验证，不能仅靠配置文件静态检查：
- 重启服务：
systemctl daemon-reload && systemctl restart myservice - 查运行时能力：
grep CapEff /proc/$(pidof myservice)/status | cut -d' ' -f2 | xxd -r -p | hexdump -C，对照 capability 位图确认无多余位被置 1 - 运行
systemd-analyze security myservice.service，查看评分是否 ≥9 分，重点关注 “CapabilityBoundingSet”、“NoNewPrivileges”、“RestrictCapabilities” 是否标记为 ✅ - 尝试在服务进程中执行
mount或strace—— 应失败并报Operation not permitted
