第 151 节 · SECTION 151

18.4 内核能力机制

传统 Linux 的权限模型非常粗放：进程分为“特权进程”（以 root 用户 UID 0 运行）和“非特权进程”（其他 UID 运行）。这带来了一个致命问题——只要一个后台服务需要一个微小的特权（例如绑定低于 1024 的端口），就必须被赋予所有的 root 权限。一旦该服务被攻陷，系统便会全面沦陷。

为了解决这一问题，Linux 引入了 能力机制（Capabilities）。它将传统的全能 root 权限划分为几十个细粒度的操作能力。

18.4.1 容器内置的 Capability 白名单

在默认情况下，即便一个容器是在以 root 用户运行，Docker 也只为其内核授予了所有可用能力中的 一小部分“白名单”能力。

常见的 Linux Capabilities 包含：

CAP_CHOWN: 修改文件所有者。
CAP_NET_BIND_SERVICE: 绑定特权端口（即 1024 以下的端口）。
CAP_NET_ADMIN: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
CAP_SYS_ADMIN: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。

为了在 “最小特权原则” 的指导下加强安全，Docker 默认 移除了 大量可能导致容器大范围破坏宿主机的能力，例如：

完全禁止了任何通过 CAP_SYS_ADMIN 进行的核心挂载或设备操作。
禁止修改内核模块。
禁止直接访问硬件套接字。

这种“非完整”的 root 用户能保证大部分应用在拥有其所需权限的同时，把恶意行为对系统的影响降到最低。

18.4.2 实战：添加与剥夺能力

当启动一个 Docker 容器时，我们可以利用 --cap-add（增加特权）和 --cap-drop（剥夺特权）两个参数精细地控制进程环境。

实战场景一：构建极限安全的 Web 靶机

假设你正在提供一个公共的 Web 容器。你不希望里面的任何恶意脚本修改进程权限或者创建设备节点，你可以通过命令先移除所有默认能力，然后再按需授权该守护进程一个仅仅能绑端口的能力。

$ docker run -d \
  --name max_secure_web \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  nginx:alpine

这里的 --cap-drop ALL 是实现“特权最小化”的最强杀手锏。此时，即便某黑客利用 0-Day 手段拿到了 Web 服务的容器 root Shell，当他试图改变任何不属于他自己的进程配置或者所有权时，系统都会报错拒绝访问。

实战场景二：需要捕获网络数据包的网络实验

假设容器内的主程序是一个网络嗅探器（如 tshark 或 tcpdump），这显然不在 Docker 提供的默认白名单之内，因为该程序试图直接操纵底层网卡流量，会触发 Permission Denied。

此时，我们需要给它适当补发缺失的部分核心管理能力：

$ docker run -it --rm \
  --name network_sniffer \
  --cap-add NET_ADMIN \
  --cap-add NET_RAW \
  tshark-image /bin/bash

我们只授予了所需的网络管理控制（NET_ADMIN）和侦听底层套接字的权限（NET_RAW），而免去了赋予整个容器终极杀器 --privileged 参数。

[!WARNING] 大量开发人员遇到了“权限遭到拒绝”的错误时，往往习惯性图省事添加 --privileged 这个核选项。但这将把 宿主机上一切特权和所有访问设备完全投射给容器内的根用户，其危险性等价于根本没有做隔离！请务必查明进程出错的实际原因，精准施加必要的隔离 CAP_* 能力。

18.4.3 总结

利用能力机制（Capabilities）是进行精细化系统级访问控制的关键一环。遵循“白名单剥夺一切不必要权利（--cap-drop ALL）”的极端配置并不过分，这将使得即便程序本身漏洞百出，攻击面也被死死压缩在一个几乎毫无后续伸展潜力的受限维度中。