Linux Capabilities 将 root 权限细分为近40个独立能力（如CAP_NET_BIND_SERVICE、CAP_SYS_ADMIN），使容器能以最小权限运行；Docker默认授予14个安全能力并移除高危项，通过--cap-add/--cap-drop动态调整，需与seccomp、user namespace协同实现三层权限控制。
linux capabilities 是 docker 安全模型中承上启下的关键一环——它既依托于内核能力框架，又直接影响容器的最小权限落地效果。理解它，不是为了记住一堆 cap_ 前缀，而是看清“为什么容器里 root 也干不了 mount”“为什么 spring boot 绑 80 端口要加 --cap-add=net_bind_service”。
Capabilities 怎么把 root 权限“切片”？
传统 Linux 中，UID 0（root）拥有全部系统特权，一旦被攻破，宿主机即失守。Capabilities 将这“一把万能钥匙”拆成近 40 把专用小钥匙，比如：
- CAP_NET_BIND_SERVICE：只管绑定 1024 以下端口（如 80、443），跟文件系统、进程调试完全无关
- CAP_SYS_ADMIN：涵盖挂载/卸载文件系统、修改命名空间、pivot_root 等，是容器逃逸高频利用项
- CAP_DAC_OVERRIDE：绕过文件读写权限检查（类似“无视 chmod 600”），但不等于能删根目录
- CAP_KILL：仅允许向其他进程发信号（如 kill -9），不能修改其内存或 ptrace 调试
每个进程在创建时可被赋予一个能力集合（bounding set + effective/permitted/inherited sets），内核在执行敏感操作前，只检查对应能力是否在当前进程的 effective 集合中——没这个“小钥匙”，哪怕 UID 是 0，也会被拒绝。
Docker 默认给了哪些能力？为什么这么选？
Docker 守护进程启动容器时，会主动丢弃高危能力，仅保留 14 个常用且相对安全的能力，包括：
- NET_BIND_SERVICE：支撑 Web 服务监听标准端口，几乎每个 Java/Spring Boot 容器都需要
- KILL、SETUID、SETGID：支持常规进程管理与用户切换，Java 应用启动子进程、降权运行依赖它们
- AUDIT_WRITE：允许写入内核审计日志，便于安全监控，但不开放审计配置权
- DAC_OVERRIDE 和 FOWNER：为兼容某些需访问受限配置文件的中间件（如 Tomcat 加载外部 conf）留出弹性
同时明确移除：SYS_ADMIN、SYS_MODULE、NET_ADMIN、SYS_PTRACE、MAC_OVERRIDE 等——这些是容器逃逸链中的常见跳板。例如，没有 SYS_ADMIN，容器内执行 mount /dev/sda1 /mnt 会直接返回 Operation not permitted。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
cap-add 和 cap-drop 的真实作用边界
--cap-add 和 --cap-drop 并非“开关式授权”，而是对默认能力集做增量/减量调整：
-
docker run --cap-add=NET_RAW nginx：在默认 14 项基础上，额外加入原始套接字能力（常用于网络诊断工具如 tcpdump） -
docker run --cap-drop=SETUID --cap-drop=SETGID openjdk:17-jre-slim：强制移除用户组切换能力，确保 Java 进程无法调用 setuid() 降权失败后回退到 root - 注意：--cap-add=ALL 不等于获得完整 root 权限——它仍受 bounding set 限制，且部分能力（如 CAP_SETPCAP）需父进程已具备才能继承
- 更关键的是：cap-add 不修复漏洞，只扩大攻击面。比如加了 SYS_ADMIN，就等于给逃逸铺好了路
和 seccomp、user namespace 如何协同？
Capabilities 单独使用效果有限，必须与其他机制联动：
- 配合 user namespace：Docker 启用 userns-remap 后，容器内 UID 0 映射到宿主机上的非 root UID，此时即使有 CAP_NET_BIND_SERVICE，也无法影响宿主机其他用户的端口绑定
-
配合 seccomp BPF 过滤：seccomp 可以禁止调用
mount()系统调用，即便容器拥有 CAP_SYS_ADMIN，该能力也因调用被拦截而失效 -
配合 AppArmor/SELinux：在 capabilities 允许的前提下，进一步按路径、类型限制文件访问（如禁止读取
/etc/shadow）
真正健壮的容器权限策略，是 capabilities 做“能做什么”，seccomp 做“不准调什么”，user namespace 做“对谁生效”的三层嵌套控制。
