capabilities 是 linux 将 root 权限拆分为 40 多个细粒度能力单元的机制，如 cap_net_bind_service、cap_sys_admin 等，旨在替代直接使用 root 以缩小攻击面；可通过 setcap 静态赋权、capsh 或 libcap 动态调控，并需注意容器适配、脚本限制及与 selinux 等机制的协同。
Capabilities 是什么，为什么不用直接给 root
Linux 的 capabilities 是把传统 root 权限拆成 40 多个细粒度的“能力单元”，比如 cap_net_bind_service（绑定 1024 以下端口）、cap_sys_admin（执行某些系统管理操作）、cap_chown（修改文件所有者）等。直接用 root 运行程序风险高，一旦被利用就等于全盘沦陷；而只赋予必要 capabilities，能大幅缩小攻击面。
常用 capability 操作命令
给二进制文件添加 capability：
- sudo setcap cap_net_bind_service=+ep /usr/local/bin/myserver —— 允许普通用户运行该程序时绑定 80/443 端口
- sudo setcap cap_sys_ptrace,cap_sys_admin=+ep /usr/local/bin/debugger —— 同时赋予两个能力
- getcap /usr/local/bin/myserver —— 查看已设置的能力
- sudo setcap -r /usr/local/bin/myserver —— 清除所有 capabilities
注意：=+ep 中 e 表示 effective（立即生效），p 表示 permitted（允许使用），这是最常用组合；若只设 p 不设 e，程序需在运行时自行调用 cap_set_proc() 启用。
运行时动态控制 capability 的要点
Capability 不仅可静态绑定到文件，还能在进程启动或运行中调整：
- 用 capsh 测试权限边界：
capsh --caps="cap_net_raw+eip" -- -c 'ping -c1 127.0.0.1' - 程序可通过
libcap库调用cap_get_proc()、cap_set_flag()、cap_set_proc()动态降权或提权 - 容器场景中，Docker 默认禁用 cap_sys_admin，但允许用
--cap-add=net_admin显式开启网络配置能力
关键原则：进程默认只继承父进程的 permitted 集合中已置为 effective 的能力；drop capability 要尽早，在完成特权操作后立刻调用 cap_clear() 或 prctl(PR_CAPBSET_DROP, ...)。
常见陷阱与安全提醒
Capabilities 不是万能补丁，误用反而引入新风险：
- cap_sys_admin 范围极广（挂载、修改内核参数、bpf 系统调用等），应避免随意授予
- 设置了 cap_setuid 的程序若未及时放弃，可能被用于提权到任意 UID
- capability 只作用于直接执行的文件，对脚本（如 bash、python）无效——因为解释器才是真正执行者；需改用
setcap给解释器本身（不推荐）或改用编译型 wrapper - SELinux/AppArmor 与 capabilities 协同工作，但策略冲突时以 MAC 框架为准，不能假设加了 cap 就一定成功
生产环境建议配合 ambient capabilities（Linux 4.3+）和 securebits（如 SECBIT_NO_SETUID_FIXUP）进一步加固。
