传统上，在 Linux 中只有超级用户 (UID=0，即 root) 拥有完整的系统权限，而非特权用户受限于正常的权限检查。从 Linux 2.2 开始，引入了 Capabilities 机制，将 root 的特权拆分成数十种更细粒度的权限位。这样可以按照“最小权限原则”赋予进程所需的最低特权：应用可以仅拥有完成任务所需的部分“root”权限，而不必拥有全部超级用户权限。在容器环境中，Capabilities 是安全隔离的重要基础：容器进程通常以 root 身份运行但默认只保留有限的 Capabilities，从而降低其破坏力。Kubernetes 和 Docker 均利用该机制，通过配置允许或剥夺某些 Capabilities，控制容器内程序的权限。
下面将详细列出常见的 Linux Capabilities，以及它们的含义、在 Linux 内核中的作用，及在容器中的影响和潜在风险。
Linux 内核目前实现了大约 40 个不同的 Capabilities。下表按类别汇总了主要的 Capabilities，每项包含其含义/作用以及在容器环境中的影响或风险。
| Capability | Linux 含义及权限 | 在容器中的影响与风险 |
|---|---|---|
| CAP_CHOWN | 允许对文件的所有者 UID 和 GID 进行任意更改。 | **影响：**容器进程可随意更改文件属主，绕过所有者检查。这在容器内意味着应用可以修改任何文件的拥有者。如果挂载了主机目录，共享卷内的文件所有权也可能被修改，造成主机文件权限紊乱。 |
| CAP_DAC_OVERRIDE | 绕过文件读、写和执行的权限检查（DAC，自主访问控制）。 | **影响：**容器进程可无视文件的 Unix 权限位进行读写操作。例如，本来无权限读取的文件在有此 Capability 时可被读取。若攻击者获取容器控制权，可能访问或篡改原本受限的文件内容。 |
| CAP_DAC_READ_SEARCH | 绕过文件只读检查，以及目录的读取/执行权限检查。还允许使用 open_by_handle_at(2) 等特殊文件访问调用。 |
**影响：**容器进程可在没有读权限的情况下读取文件或目录列表。这增加了信息泄露风险，攻击者能遍历或读取本应不可见的目录结构和文件。 |
| CAP_FOWNER | 绕过某些与文件所有权相关的权限检查（例如修改文件权限chmod、修改时间戳utime），即使当前进程并非该文件所有者。还允许忽略目录粘滞位删除文件等。 |
**影响：**容器内进程可修改任意文件的权限和属性（除了另有专门 Cap 控制的情形），即使不拥有该文件。这可能被利用来篡改应用文件、提升权限（如将可执行文件设置为 Setuid）。在共享卷场景下，可能影响主机上的文件属性。 |
| CAP_FSETID | 文件被修改时不清除其 Set-UID/Set-GID 位；允许在不匹配文件当前 GID 的情况下设置文件的组ID位。 | **影响：**容器进程修改带 Setuid/Setgid 的程序时，可保留这些特权位，从而在容器内维持提权机制。同时也可在创建文件时设置任意组ID位。可能被攻击者用于维持权限提升的后门（如保留Setuid位的恶意程序）。 |
| CAP_MKNOD | 允许使用 mknod(2) 创建设备特殊文件（如块设备、字符设备）。 |
**影响：**容器内进程可创建新的设备文件节点。如果容器还拥有对相应设备的访问权限（受 cgroup 设备控制），则可能直接与主机硬件交互，带来安全隐患。通常默认情况下容器的 cgroup 设备策略会阻止访问未授权设备，但赋予 CAP_MKNOD仍是高风险操作。 |
| CAP_LINUX_IMMUTABLE | 可设置文件不可变标志和追加写入标志（FS_IMMUTABLE_FL, FS_APPEND_FL）。 |
**影响：**容器进程可将文件标记为不可变或只能追加，改变文件系统行为。例如攻击者可将关键配置文件标记不可变以阻止修改，或者恶意程序利用此限制日志只能追加无法删除。虽然这不直接破坏隔离，但可能被用来妨碍运维或取证。 |
| CAP_LEASE | 可对任意文件设置文件租约（leases）。文件租约允许进程监视对文件的打开/关闭等事件。 | **影响：**容器进程可对文件施加租约，从而控制文件访问的同步。这主要用于文件锁定机制，本身危害不大。但恶意程序可能利用租约阻塞其他进程对某文件的访问（造成DoS），或监视宿主对共享文件的操作。 |
| CAP_SETFCAP | 允许对文件设置 文件Capabilities（即给可执行文件附加特权位）。 | **影响：**容器内可通过为可执行文件设置特殊Capabilities来提升该程序执行时的权限。例如给二进制文件赋予网络或管理特权。通常Docker镜像构建时会去除文件上的Capabilities扩展属性，但若容器运行时具有CAP_SETFCAP，攻击者可能自行赋予文件额外特权，从而在下次运行时获得更高权限。 |
解读： 上述 Capabilities 涉及对文件和文件系统权限的控制，在容器中默认 应尽量减少授予。例如，Docker 默认启用 CAP_CHOWN 等基本文件操作能力，但像 CAP_DAC_OVERRIDE 这类可绕过权限检查的能力默认是不赋予容器的，以防止容器绕过文件系统的隔离限制。即便如此，哪怕基本的文件操作权限，也可能在共享卷场景下被利用对宿主文件造成影响，因此需要根据实际需求谨慎添加或放权。
| Capability | Linux 含义及权限 | 在容器中的影响与风险 |
|---|---|---|
| CAP_SETUID | 允许对进程的用户ID进行任意修改（例如调用setuid(2)将进程切换为任意UID）。 |
**影响：**容器内进程可将自身切换为任意用户，包括提升为root或降为其他用户。这对非root进程提权有用。但在容器内由于默认即为root用户启动，此Capability主要影响从root降权的灵活性。如果攻击者获取非root的容器进程并拥有CAP_SETUID，可切换为root，提升在容器内的权限。 |
| CAP_SETGID | 允许对进程的组ID和辅助组列表进行任意修改。 | **影响：**类似CAP_SETUID，容器进程可更改其组身份。攻击者利用它可加入受限制的组以获取额外权限。不过默认容器即root组，此能力更多用于在容器内做细粒度权限管理。在恶意情形下，可配合CAP_SETUID实现进程身份完全伪装。 |
| CAP_SETPCAP | 允许修改进程的Capability集合，例如向自身继承集添加目前 bounding set 中允许的Capabilities，或从 bounding set 中移除Capabilities。 | **影响：**容器内进程可调整自身及子进程的特权位。如果容器运行时 bounding set 限制了某些 Cap，这个能力通常也无法突破该限制（Linux 内核默认不允许进程将不在边界集的Capability添加回来）。因此该Capability主要用于_降低_权限。但在不常见的配置下，可能被利用来重新启用某些被临时移除的特权。一般容器不需要授予此Capability。 |
| CAP_KILL | 绕过信号发送的权限检查，允许向任意进程发送信号（包括向不属于同一用户的进程发送kill信号）。 |
**影响：**容器内进程可向容器中的其他进程发送信号（SIGKILL等）而不需考虑UID是否相同。这对容器自身内部的进程管理有用（Docker 默认保留该能力）。但默认情况下容器的进程隔离(pid namespace)使其看不到宿主或其他容器的进程，所以CAP_KILL影响局限于容器内部。如果禁用了PID隔离（如Kubernetes的hostPID: true模式），CAP_KILL将允许容器向宿主上任意进程发信号，这是严重的权限泄露。 |
| CAP_SYS_PTRACE | 允许跟踪（调试）任意进程，即使用ptrace对其他进程进行检查和操作。也允许通过/proc读取其他进程的敏感信息（如内存、文件描述符）。 |
**影响：**默认容器启用PID命名空间，因此即使有CAP_SYS_PTRACE也只能调试容器内的进程。这仍可能带来风险：恶意程序可窥探同容器其他进程的内存（窃取机密信息）或注入代码。如果容器与宿主共享PID命名空间（非常不建议），那么拥有CAP_SYS_PTRACE的容器进程可以调试宿主上的进程，达到完全控制和数据窃取的程度。因此除非有调试需求，应避免容器获取此Capability。 |
| CAP_SYS_NICE | 允许调整进程调度优先级和调度策略，包括降低任意进程的nice值（提高优先级）或将进程设为实时调度等。也允许将任意进程绑定CPU亲和性、内存节点等（迁移进程到其他CPU/NUMA节点）。 | **影响：**容器内拥有此能力可使进程提高自己的或他进程的优先级，从而独占更多CPU（可能影响同容器其他服务）。如果一台宿主上多个容器共享CPU，某容器滥用CAP_SYS_NICE可能导致CPU饥饿攻击。不过通常各容器间CPU隔离靠cgroups控制，此Capability影响主要在容器内部。除实时应用需要，一般不应赋予容器该能力。 |
| CAP_SYS_RESOURCE | 允许覆盖资源限制和配额，例如绕过ulimit/RLIMIT约束（增加进程最大文件句柄数、内存锁定大小等），超越磁盘配额限制，保留ext文件系统的预留空间等。还能提高POSIX消息队列配额、调低进程的 OOM 分数（避免被OOM杀死）等。 |
**影响：**容器进程可突破分配给它的某些资源限制。例如，若容器被设置了文件句柄或内存限制，有CAP_SYS_RESOURCE时可自行提高这些限制。这可能导致容器消耗超过预期的资源甚至影响宿主稳定性（如耗尽主机文件描述符表）。因此默认容器不应具有此能力。Kubernetes 和 Docker 通常通过 cgroups 实施资源限制，CAP_SYS_RESOURCE的滥用可绕过部分cgroup限制（如进程数），带来DoS风险。 |
| CAP_SYS_CHROOT | 允许调用chroot(2)改变进程根目录，并在进入其他 mount namespace 时无需额外权限。 |
**影响：**容器内进程可自行对自身执行chroot操作。容器本身就是一种chroot环境，因此此能力通常作用不明显。大多数应用无需在容器内再次chroot，因此可考虑去除。攻击者获得该能力也难以突破容器，因为仍受限于容器的文件系统命名空间。 |
| CAP_SYS_PACCT | 允许启用或禁用进程计帐 (acct(2))，即开启/关闭系统级的进程资源统计功能。 |
**影响：**容器内几乎不会用到开启宿主级进程计帐的功能（宿主通常不允许容器直接操作全局计帐）。即使赋予此能力，若容器有独立的 PID 和文件系统命名空间，它也只能影响容器内部（但通常计帐是全局的，容器可能无法真正执行）。此Capability风险较低但无必要，默认应移除。 |
解读： 以上涉及进程管理的 Capabilities 在容器中一般也不是默认全部授予的。Docker 默认仅保留其中的少数（例如 CAP_KILL）。大部分如 CAP_SYS_PTRACE、CAP_SYS_NICE 等都不在默认集内，因为它们对系统其他进程或资源有较大影响。如果容器需要这些能力（如需在容器内调试程序，则需要 CAP_SYS_PTRACE），应在严格限制范围的情况下按需添加，并确保隔离（如不要与宿主共享 PID namespace），以免造成越权访问。
| Capability | Linux 含义及权限 | 在容器中的影响与风险 |
|---|---|---|
| CAP_NET_BIND_SERVICE | 允许将套接字绑定到特权网络端口（端口号<1024）。 | **影响：**容器进程可以监听低号端口（例如80, 443）而无需提升为宿主机上的root。这对运行Web服务器容器很有用（Docker 默认保留此能力）。安全风险相对较小，因为仅影响容器自身网络命名空间。不过，如不需要低端口监听，可移除此能力来迫使应用使用高端口映射，从而降低潜在滥用。 |
| CAP_NET_BROADCAST | （已废弃） 允许进行网络广播和多播监听。 | **影响：**该能力在现代内核中未被使用，Docker/K8s 中通常无效。因此对容器无实际影响，可以忽略。 |
| CAP_NET_ADMIN | 允许执行多种网络相关管理操作，例如配置网络接口、管理路由表、防火墙规则、启用侦听模式等。 | **影响：**容器进程可对网络进行广泛控制。例如，它可以修改容器内网络接口IP、路由和iptables规则等。正常情况下容器网络与宿主隔离，所以这些操作仅作用于容器自身网络命名空间。但这仍存在风险：恶意容器可通过修改路由/iptables来拦截或篡改经过容器的流量。如果容器使用主机网络（Docker --network=host 或 K8s hostNetwork: true），那么CAP_NET_ADMIN将直接影响宿主网络设置，包括更改主机接口配置、防火墙等，严重危及主机网络安全。因此非必要不应赋予容器该权限。 |
| CAP_NET_RAW | 允许使用RAW套接字和PACKET套接字，进行底层网络通信；也允许绑定网络接口用于透明代理。 | **影响：**具备此能力，容器可构造原始网络包（例如发送自定义IP包，执行ARP欺骗等）。Docker 默认保留该能力以支持ping等工具运行。在容器网络隔离情况下，RAW套接字流量通常局限在容器自身网络namespace内。然而恶意容器仍可利用它进行网络扫描、流量嗅探甚至发起基于IP包的攻击。如果容器网络与宿主未隔离，风险更高。所以对不需要底层网络访问的应用，可考虑去除CAP_NET_RAW。 |
解读： 网络类 Capabilities 默认配置上 相对保守。Docker 默认允许 NET_BIND_SERVICE 和 NET_RAW，以支持常见网络服务和Ping等操作，但不赋予NET_ADMIN，因为后者权限过大。对于需要复杂网络配置的容器（例如运行自定义路由/负载均衡软件），可能需要 CAP_NET_ADMIN，但应确保容器网络隔离良好，避免影响其他容器或宿主。原则上，容器应仅拥有其职能所需的最低网络权限。
| Capability | Linux 含义及权限 | 在容器中的影响与风险 |
|---|---|---|
| CAP_IPC_LOCK | 允许锁定内存，防止内存页被交换到磁盘（使用mlock, mlockall等），并允许使用大页内存分配。 |
**影响：**容器进程可将内存页锁定在RAM中，增大其常驻内存占用。例如数据库或缓存应用可能需要此权限来防止关键数据被swap出去。如果滥用，恶意进程可以锁定大量内存而不受swap缓解，可能导致宿主内存压力增大甚至耗尽。幸好cgroups内存限制通常仍对其生效，但没有CAP_IPC_LOCK时调用mlock会失败。因此仅当应用明确需要（如Memcached需要锁定内存）才添加此Capability。 |
| CAP_IPC_OWNER | 绕过对 System V IPC 对象（如共享内存段、信号量）的权限检查。 | **影响：**容器进程可访问/控制所有的 SysV IPC 资源，即使并非它们的创建者。在启用了 IPC Namespace 的容器中，该影响局限于容器内部的IPC对象；但如果容器与宿主共用IPC命名空间（很少见的配置），攻击者可访问宿主的IPC对象，造成信息泄露或干扰。通常容器不需要直接操作宿主的SysV IPC，因此应避免授予此能力。 |
解读： 这两项Capability涉及进程间通信和内存。大部分应用容器默认不具有这两项特权，因为它们并非通用需求，而且滥用可能导致对宿主资源的影响（内存锁定导致宿主内存紧张等）。如果需要使用诸如 memlock 的功能，应在评估风险后在容器运行时通过--cap-add IPC_LOCK显式开启，并搭配内存限额以防止滥用。
| Capability | Linux 含义及权限 | 在容器中的影响与风险 |
|---|---|---|
| CAP_SYS_ADMIN | （系统管理“万能”权限） 此Capability涵盖广泛的系统管理操作，包括挂载和卸载文件系统、调用pivot_root改变根、启用交换、设置主机名/域名等。它还隐含许多子功能，例如所有新引入的 CAP_BPF、CAP_PERFMON、CAP_CHECKPOINT_RESTORE 等在没有独立赋予时也被CAP_SYS_ADMIN覆盖。由于范围极广，CAP_SYS_ADMIN被称为“新的root权限”。 |
影响：这是容器中最危险的Capability。赋予容器CAP_SYS_ADMIN几乎等同于赋予其root权限，可以进行大量特权操作（如挂载宿主文件系统、访问设备、进行系统调试等）。实践表明，仅有CAP_SYS_ADMIN的容器便可利用内核接口实施逃逸。例如，攻击者曾利用具有CAP_SYS_ADMIN的容器挂载宿主的cgroup文件系统并结合notify_on_release机制取得宿主shell。总之，在非特权容器场景下一定要避免给容器此权限；如果必须使用，应将容器视为全权限并采取隔离措施（如独立主机运行）。 |
| CAP_SYS_MODULE | 允许加载和卸载内核模块（init_module, delete_module）。 |
**影响：**容器可向宿主内核加载任意模块或卸载现有模块，等同于对内核植入代码。这是非常高危的操作：攻击者可加载恶意内核模块取得对宿主的完全控制。因此此Capability绝不应赋予普通容器。在需要时通常通过--privileged（授予所有能力）来运行特殊容器，例如硬件驱动容器，但这意味着放弃隔离。 |
| CAP_SYS_RAWIO | 允许执行原始I/O操作，包括直接访问硬件I/O端口（iopl/ioperm）、访问/dev/mem和/dev/kmem（物理内存）、读取内核内存映像/proc/kcore等。 |
影响：具备此能力的容器进程可以绕过操作系统提供的设备文件接口，直接对内存和硬件进行读写。这意味着攻击者可读取整个主机内存内容或修改硬件寄存器等，几乎可完全控制主机。这在容器环境下是极其危险和不必要的，默认绝不会赋予容器。如需访问特定设备，应通过设备节点挂载和cgroup设备白名单控制，而不开放SYS_RAWIO。 |
| CAP_SYS_TIME | 允许设置系统时钟和实时硬件时钟。 | 影响：如果容器没有独立时间命名空间（当前大多数容器和宿主共用系统时间），则赋予该能力的容器可以更改宿主的系统时间。这可能导致日志时间篡改、安全协议失效（例如TLS证书验证依赖时间）等严重问题。即使将来时间命名空间隔离，此能力影响也应谨慎对待，因为不正确的时间可能扰乱分布式系统行为。一般容器不需要修改系统时间，除非运行时间同步服务，此时应隔离容器使之不会影响宿主。 |
| CAP_SYS_TTY_CONFIG | 允许配置TTY设备，例如使用vhangup(2)挂起一个终端，以及对虚拟终端执行某些特权ioctl操作。 |
**影响：**容器进程可操作系统的TTY/控制台，例如强制注销某终端的会话。这能力主要对宿主控制台有意义。在容器内，其用途很有限，风险也不高。但若容器共享了宿主的TTY设备（极少情况），攻击者可能利用它干扰宿主的终端。通常无需赋予容器该权限。 |
| CAP_SYS_BOOT | 允许调用reboot(2)重新启动系统或kexec_load(2)加载新内核。 |
**影响：**如果容器具有此能力并能访问适当的设备接口，它可以直接触发宿主机重启或替换内核！这对宿主而言是毁灭性的（拒绝服务甚至持久控制）。因此除非是在受控环境中运行特权系统管理容器，否则绝不应赋予。这一权限通常只由系统初始化进程或管理员进程在宿主上使用。 |
| CAP_SYSLOG | 允许执行特权的syslog(2)操作（例如读取或清除内核环缓冲区），以及在kptr_restrict设置为1时读取内核地址等敏感信息。 |
**影响：**容器可读取内核日志、提取潜在敏感的内核地址信息，或调整内核日志行为。这可能泄露宿主内核的信息（有助于攻击者利用漏洞）。默认容器不具有此能力。在大多数情况下不需要授予容器对宿主内核日志的控制权限。 |
解读： 这一组Capbilities涉及系统级的管理控制，通常只有宿主管理员才需要。Docker/Kubernetes 默认完全禁止容器使用这些能力，因为它们几乎都可以用于突破容器隔离或直接控制宿主。特别是CAP_SYS_ADMIN，它覆盖功能最多，也是历次容器逃逸漏洞中最常被利用的权限。实践经验表明，如果发现容器需要上述某项能力，很可能意味着该容器应该提升为“特权容器”而在隔离环境下运行，而不应轻易在多租户环境下赋予单一Capability。总之，普通应用容器不应具备这些系统管理特权。