Linux 服务怎样按 capability 缩小权限

Linux 服务不一定要以 root 运行。更稳妥的做法是先找出它真正需要的特权，再用 capability 只开放这一小块能力。例如服务只需要监听 443 端口，可以考虑 CAP_NET_BIND_SERVICE，而不是把整个进程交给 root。这样即使应用本身出现缺陷，进程可利用的内核特权也更少。

官方资料：https://www.kernel.org/doc/html/latest/

先按实际动作选择 capability

Linux capability 是按线程拆开的特权单元，常见服务需求与能力并不是一一对应的“安全标签”。先写出服务的动作，再查对应能力，避免看到报错就直接加上宽泛的 CAP_SYS_ADMIN。这个能力覆盖很多系统管理操作，边界很大，通常应当作为最后的例外处理。

用 systemd 把服务权限缩到最小

以只需监听低端口的服务为例，unit 可以把身份、能力边界和继承关系写在一起。下面的配置是一个起点，服务名和可执行文件请替换成实际值：

[Service]
# 先用普通用户运行，避免把 root 身份当作默认权限
User=app
Group=app
ExecStart=/usr/local/bin/collector

# 只保留绑定低端口所需的能力
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# 普通用户执行程序时，允许它继承这一项能力
AmbientCapabilities=CAP_NET_BIND_SERVICE
# 禁止进程通过 execve 获得新的特权
NoNewPrivileges=yes

CapabilityBoundingSet 控制能力边界；写成一项时，其他能力不会因服务环境而继续保留。AmbientCapabilities 的用途是让非 root 程序在执行过程中拿到明确列出的能力，前提是它同时受 bounding set 约束。若程序并不需要跨执行文件继承能力，可以先不加这一行，减少配置面。

# 修改 unit 后重新加载配置并重启服务
sudo systemctl daemon-reload
sudo systemctl restart collector.service

# 查看 systemd 记录的关键权限属性
systemctl show collector.service \
  -p User -p Group -p CapabilityBoundingSet \
  -p AmbientCapabilities -p NoNewPrivileges

配置生效后检查哪几层

只看 unit 文件不够。先确认服务实际启动的是哪个 PID，再观察进程能力。systemctl show 反映 systemd 的解析结果，/proc//status 反映进程当前集合，两者不一致时应优先查启动命令、包装脚本和服务是否真的重启。

# 读取服务主进程 PID；空值通常表示服务没有成功启动
pid=$(systemctl show -p MainPID --value collector.service)
if [ "${pid}" -gt 0 ]; then
  # CapEff 是当前有效能力集合，CapBnd 是进程能力边界
  grep -E '^(Uid|CapEff|CapPrm|CapAmb|CapBnd):' "/proc/${pid}/status"
fi

权限收敛要和功能回归一起做：低端口绑定正常，不代表文件读取、日志写入或网络管理也正常。按失败的具体动作补充单项能力，并记录原因；不要用“加回全部权限”作为排障捷径。

三个容易误判的边界

• 低端口不是必须使用 capability。如果前置代理可以监听 443，再把流量转发给高端口应用，应用甚至可以不保留 CAP_NET_BIND_SERVICE。
• capability 不是文件和目录权限。服务仍需要正确的 UID、GID、ACL 和路径权限；capability 只影响受内核保护的特定特权动作。
• 能力缩小不等于完整沙箱。网络、文件系统、系统调用和资源消耗仍可用其他 systemd 或内核机制继续限制，不能把 capability 当作万能隔离。

常见问题

CapabilityBoundingSet 写空值是什么意思？

在 systemd 语境中，空的能力边界可用于清空服务的 bounding set，但具体 unit 继承关系仍要结合覆盖配置检查。对于生产服务，显式写出需要保留的能力通常更容易审查。

为什么加了 CAP_NET_BIND_SERVICE 仍然绑定失败？

检查服务是否真的使用了该 unit、程序是否由包装脚本再次执行、能力是否进入有效集合，以及端口是否已经被其他进程占用。先看 CapEff，不要只看配置文件。

CAP_SYS_ADMIN 可以直接解决权限问题吗？

它可能覆盖多个系统管理动作，但权限范围过宽。应先把失败系统调用映射到更窄的 capability；只有无法拆分且经过评估时才保留它。