Linux Capabilities 详解：进程权限控制的艺术

父进程: 子进程PID=101
子进程: 子进程: PID=101

shell (PID=100)
  fork() → 子进程 (PID=101，是 shell 的克隆)
    execve("/bin/runc", ...) → PID=101 的进程变成了 runc
      runc 开始运行

CapInh: 0000000000000000   # Inheritable
CapPrm: 000001ffffffffff   # Permitted
CapEff: 000001ffffffffff   # Effective
CapBnd: 000001ffffffffff   # Bounding
CapAmb: 0000000000000000   # Ambient

启动时：
  CapPrm = cap_net_bind_service, cap_setuid, cap_sys_admin ...
  CapEff = cap_net_bind_service  ← 绑定 80 端口时短暂需要

bind() 完成后：
  CapEff = 空  ← 用完了就丢

处理 10000 个 HTTP 请求：
  CapEff = 空  ← 正常工作不需要任何特权

遇到 CGI 脚本需要执行：
  CapEff = cap_setuid  ← 临时开启
  执行完成
  CapEff = 空  ← 再丢

... 如此循环 ...

父进程：
  CapInh = {cap_net_bind}
  CapPrm = {cap_net_bind}
  CapEff = {cap_net_bind}

fork() 后：
  子进程自动继承：
    CapInh = {cap_net_bind}
    CapPrm = {cap_net_bind}（子进程从父进程继承 CapPrm）
    CapEff = {cap_net_bind}

子进程立刻丢弃 CapEff：
    CapPrm = {cap_net_bind}（还在包里，没丢）
    CapEff = 空

→ 如果子进程被攻击者利用，攻击者拿到的是 CapEff = 空
  而不是 CapPrm = {cap_net_bind}

CapBnd = 你的"最高学历"（博士）
         → 你这辈子最多拿到博士学位，不可能再高了
         → 即使丢了，以后也不可能再拿回来（除非重启）

CapPrm = 你包里的"证件"（工程师证 + 教师证 + ...）
         → 可以随时丢弃，也可以随时考新的补回来

宿主机 runc 进程：
  CapBnd = 全开（40 个 capability 都有）
  CapPrm = 全开
  CapEff = 全开

容器创建时，runc 会裁剪容器的 CapBnd（去掉 cap_sys_admin 等）：
  容器内进程：
    CapBnd = {去掉 CAP_SYS_ADMIN}     ← 内核强制限制！
    CapPrm = {去掉 CAP_SYS_ADMIN}
    CapEff = {去掉 CAP_SYS_ADMIN}

  → 即使容器内进程通过漏洞提权成功，也无法执行 mount()/unshare()/chroot()
    因为这些操作需要 CAP_SYS_ADMIN，而 CapBnd 里没有

父进程：
  CapInh = {cap_net_bind_service}
  fork()
    ↓ 子进程继承
  子进程 CapInh = {cap_net_bind_service}（自动有）
  子进程 CapPrm = {cap_net_bind_service}（从 CapInh 继承）

普通进程（无 root）：
  execve("/bin/ls", ...)
    → 丢失所有 capabilities（因为 ls 不是 setuid 程序）

普通进程：
  CapPrm = {cap_net_bind_service}
  CapEff = {cap_net_bind_service}
  CapAmb = {cap_net_bind_service}  ← 标记了"exec 后保留"

  execve("/bin/myprogram", ...)
    → myprogram 仍然有 cap_net_bind_service

nginx master 进程（root）：
  CapInh = {cap_net_bind_service}  ← 设置了需要继承的能力
  fork()
    ↓ 子进程继承
  nginx worker 进程：
    CapPrm = {cap_net_bind_service}（从 CapInh 继承）
    CapEff = {cap_net_bind_service}

普通用户进程：
  CapAmb = {cap_net_bind_service}
  execve("/usr/sbin/my-server", ...)
    → my-server 仍然可以绑定 80 端口（即使不是 root）

进程启动（exec）：
  CapBnd = 内核 cap_last_cap 决定的最大集合（通常 40 个全开）
         ↓
  CapPrm = 继承自父进程
         ↓
  CapEff = 继承自父进程
         ↓
  CapInh  = 继承自父进程（可被程序显式修改）
         ↓
  CapAmb  = 继承自父进程（可被程序显式修改）

CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,
cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,
cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,
cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,
cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,
cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,
cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap ...

用户程序 ──read()──→ 内核
用户程序 ──write()──→ 内核
用户程序 ──mount()──→ 内核  ← 高危！
用户程序 ──unshare()──→ 内核  ← 高危！

没有 Seccomp：
  程序 ──mount──→ ✅ 通过  ← 危险！

有 Seccomp（只允许 read/write/exit）：
  程序 ──mount──→ ❌ 拒绝（返回 -1，errno = EPERM）

允许：read, write, exit, sigreturn
禁止：mount, unshare, mknod, chroot, ...

Capabilities 检查在内核 syscall 处理函数内部（有证才放行）
Seccomp 过滤在 syscall 到达处理函数之前就拦截了

攻击者通过漏洞获取了 CAP_SYS_ADMIN：

只有 Capabilities：
  mount() ──→ 有 CAP_SYS_ADMIN ──→ 成功 ⚠️ 容器逃逸！

叠加 Seccomp：
  mount() ──→ Seccomp 拦截 ──→ EPERM ❌
              即使有 CAP_SYS_ADMIN 也白搭

Capabilities = 保安（检查你有没有通行证）
Seccomp      = 门上锁（直接物理上禁止开这扇门）

永久配置（文件级别）：
  setcap cap_xxx+ep /path/to/binary
          ↓
  文件有 extended attributes (xattr)
          ↓
  exec() 时内核自动加载到进程

临时配置（进程级别）：
  capsh / cap_set_proc()
          ↓
  只影响当前进程和子进程
          ↓
  进程退出就没了

容器内配置：
  docker run --cap-add=xxx
          ↓
  改写容器的 CapBnd/CapPrm
          ↓
  runc 通过 libcontainer 应用到容器进程