cap_sys_admin 是最危险的能力之一，覆盖挂载、命名空间、设备管理、ebpf、perf 等数十种高危操作，实际权限接近 root；应优先用 cap_net_bind_service、cap_bpf 等细粒度能力替代，或通过 volume、ulimit、--device 等无特权方案实现。
Linux 的 CAP_SYS_ADMIN 不是“小权限”，而是最危险的能力之一。它覆盖挂载、命名空间、设备管理、内核模块加载等数十种高危操作，实际权限接近 root。真正安全的做法不是授予它，而是识别需求后用更细粒度的能力替代，或改用无需特权的架构方案。
CAP_SYS_ADMIN 到底能做什么
这个能力不是单一功能，而是一组系统级管理权限的集合。常见可触发的操作包括：
- 执行 mount/umount —— 可挂载任意文件系统，包括宿主机路径
- 调用 setns —— 进入其他进程的命名空间，是容器逃逸的关键跳板
- 修改 /proc/sys/fs/file-max 等全局内核参数
- 使用 bpf() 系统调用加载 eBPF 程序，可能绕过监控
- 通过 fanotify_init 监控并拦截全系统文件访问
- 调用 perf_event_open 获取内核级性能数据，含敏感内存信息
为什么它特别危险
在容器或受限环境中，CAP_SYS_ADMIN 往往成为提权链的终点。例如：
- 攻击者可在容器内挂载宿主机根目录，直接读写关键配置
- 结合 cgroup v1 的 devices.allow 绕过，解除设备访问限制后打开 /dev/kmsg 或 /dev/mem
- 利用 setns 进入 init 命名空间，再 fork 出拥有完整权限的新进程
- systemd 服务若配置了 AmbientCapabilities=CAP_SYS_ADMIN，子进程可能意外继承并滥用
不依赖 CAP_SYS_ADMIN 的替代方案
多数场景其实不需要这么宽泛的权限：
- 需要挂载？改用 --tmpfs 或预绑定 volume，由宿主机完成挂载
- 要调整文件描述符上限？通过 systemd 的 LimitNOFILE= 或 ulimit 启动参数设置
- 需访问特定设备？用 --device=/dev/sda 或 cgroup devices.allow 白名单控制
- 要运行 eBPF 工具？启用 CAP_BPF + CAP_PERFMON，而非 CAP_SYS_ADMIN
- 时间同步需求？用 CAP_SYS_TIME，而不是整个管理能力集
如何检查和收紧现有配置
主动发现风险比事后响应更重要：
- 查所有带 CAP_SYS_ADMIN 的二进制：
getcap -r / 2>/dev/null | grep sys_admin - 看某进程当前有效能力：
cat /proc/PID/status | grep CapEff，解码用capsh --decode=0x... - systemd 服务中禁用它：
CapabilityBoundingSet=~CAP_SYS_ADMIN - Docker 启动时显式丢弃：
docker run --cap-drop=SYS_ADMIN ... - Kubernetes Pod 中限制：
securityContext.capabilities.drop: ["SYS_ADMIN"]
