Linux Capabilities 是权限分层中的“能力闸门”，将 root 权限拆解为可独立开关的细粒度单元，位于 UID/GID 和 DAC 底层之上、seccomp/SELinux 等强制策略之下，需与非 root 用户运行、安全模块联动及运行时审计协同构成多层防御。
Linux Capabilities 是构建多层防御体系的关键一环，它把传统 root 权限拆解为可独立开关的细粒度能力单元，让进程只拥有完成任务所必需的那几项特权。这本身不是“最终防线”，而是和用户隔离、文件系统控制、内核策略等协同工作的中间层——既不能单独依赖，也不能跳过。
明确 Capabilities 的定位：权限分层中的“能力闸门”
Capabilities 处在 Linux 权限模型的中间位置：底层是 UID/GID 和 DAC（自主访问控制），上层是 seccomp、AppArmor、SELinux 等强制策略。它的作用不是替代其他层，而是精准收窄系统调用入口：
- DAC 决定“能不能读 /etc/shadow”——靠 uid/gid 和文件权限位
- CAP_DAC_OVERRIDE 或 CAP_DAC_READ_SEARCH 才决定“绕过 DAC 是否被允许”
- seccomp 进一步限制“即使有 CAP_DAC_READ_SEARCH，也不许调用 openat()”
- AppArmor 则规定“该进程只允许读取 /etc/passwd，禁止访问 /etc/shadow，无论有没有 capability”
与非 root 用户运行结合：双重身份约束
仅靠 Capabilities 不足以防住提权链。必须配合以非 root 用户启动容器或服务：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 默认情况下，Docker 容器继承 14 项基础 capability（如 CHOWN、DAC_OVERRIDE），但这些能力在非 root 用户下多数失效或受限
- 例如：CAP_NET_BIND_SERVICE 允许绑定 80 端口，但若进程 UID ≠ 0，它不会自动获得读写 /proc/sys/net/ 的权限——这就阻断了部分网络配置类逃逸路径
- 推荐模式：先 USER 1001，再 cap_drop: ALL + cap_add: NET_BIND_SERVICE，而非反过来
与安全模块联动：Capability 是触发条件，策略是执行判决
CAP_SYS_ADMIN 是高危能力，但并非所有使用它的操作都该被禁止。此时需靠上层策略做动态裁决：
- 启用 seccomp profile 后，即使容器拥有 CAP_SYS_ADMIN，也无法调用 mount() 或 umount() 系统调用
- AppArmor 可定义：允许该进程执行 chroot()（需 CAP_SYS_CHROOT），但禁止其挂载 tmpfs 或 bind-mount /host
- Kubernetes SecurityContext 中同时配置 capabilities.drop: ALL 和 seccompProfile.type: RuntimeDefault，实现能力屏蔽 + 系统调用白名单双保险
运行时审计与持续收敛：从“配置即代码”到“权限即指标”
最小权限不是一次配置就一劳永逸的事。应将 Capabilities 纳入可观测性闭环：
- 定期扫描容器进程的 CapEff 字段：
cat /proc/$PID/status | grep CapEff，比对是否超出预期值 - 在 CI/CD 流水线中加入检查项：镜像构建后自动运行
getcap -r /usr/bin/ 2>/dev/null，报出任何非预期的 setcap 设置 - 将 capability 使用情况作为 SLO 指标之一，例如：“99% 的生产 Pod 能力集合大小 ≤ 2 项”
