第一次看见rm -rf /这种命令时很多人的反应是这行字真的会删掉所有文件吗在物理机上答案是肯定的在虚拟机里答案也是肯定的。但如果把它放进 Ubuntu 容器里执行事情就变得有意思了容器会在几秒内“死亡”宿主机却通常毫发无损。这不是玄学而是 Linux 内核提供的 Namespace、cgroups、Capabilities 和分层文件系统在按各自的规则保护边界。这篇文章想把几类在 Linux 圈子里流传已久的“死亡命令”放进 Ubuntu 22.04 容器中逐一审视解释它们为什么危险、在容器里执行后到底会发生什么以及哪几种错误的启动方式会让死亡命令直接打穿容器边界、波及宿主机。读完之后你会对 Docker 隔离能力有一个更准确的判断容器不是第二台操作系统而是一个有边界的安全沙箱边界设置得好死亡命令只是毁了容器自己边界设置得差死亡命令就能变成宿主机的灾难。我先把结论放在前面普通容器里执行rm -rf /删除的是容器自身的可写文件系统视图不影响镜像层和宿主机但如果你用-v /:/host挂载了宿主机根目录或者加了--privileged特权模式再配合rm -rf /host/*这样的操作宿主机真实文件一样会被删除。破坏力的大小从来不取决于命令本身而取决于你启动容器时交出去多少权限。1. 为什么要在容器里谈“死亡命令”容器技术普及之后很多开发者会产生两种相反的安全错觉。第一种错觉是“容器里很安全随便乱搞不会出大事”。于是有人在生产环境容器里执行rm -rf /想重置环境结果容器内所有命令瞬间不可用业务容器直接瘫痪。第二种错觉是“容器完全等同于虚拟机隔离能力应该由系统兜底”于是有人放心地把宿主机的根目录挂载进容器结果容器里一条删除命令就清空了宿主机数据。这两种极端都源于对容器隔离边界的误解。rm -rf /这类“死亡命令”恰好是最好的实验材料它们对普通 Linux 主机的破坏路径是明确的只要把同样一批命令放进容器里执行隔离机制的边界就会立刻显示出来。你会看到有些命令被 Namespace 挡住有些命令被只读挂载挡住有些命令因为 Capabilities 缺失而无从下手也有些命令因为错误的挂载参数直接穿过隔离层。这篇文章就是围绕这个实验展开的。我会先列出常见的死亡命令和它们的破坏路径再讲清楚容器是靠哪些机制实现隔离的接着在 Ubuntu 容器里逐个执行这些命令最后总结哪些运行参数会让隔离失效以及生产环境中应该怎样设置容器安全基线。2. 先认识这些传说中的死亡命令在进入容器实验之前先明确一个基础问题死亡命令到底有哪些它们为什么能杀死一台 Linux 主机。命令作用为什么被称为“死亡命令”rm -rf /递归删除根目录下所有文件删除整个文件系统系统瞬间无法运行:(){ :|: };:Bash fork 炸弹无限创建进程耗光 PID 和 CPUmkfs.ext4 /dev/sda格式化磁盘清空磁盘文件系统数据全部丢失dd if/dev/zero of/dev/sda向磁盘写入零数据覆盖磁盘上的所有数据无法恢复chmod -R 777 /递归修改根目录权限破坏系统权限体系服务无法正常访问文件mv / /dev/null尝试把根目录移动到空设备在部分配置下导致系统无法启动内存炸弹如死循环分配内存持续申请内存耗尽系统内存触发 OOM甚至拖垮宿主机这些命令在物理机或虚拟机上的后果非常直观。rm -rf /会清空根文件系统mkfs和dd直接操作块设备把磁盘数据抹掉fork 炸弹则通过资源耗尽让系统失去响应。有一个细节值得注意GNU coreutils 版本的rm对根目录是存在保护的。在绝大多数现代发行版上直接执行rm -rf /会收到提示rm: it is dangerous to operate recursively on / rm: use --no-preserve-root to override this failsafe所以要在 Linux 主机上真正触发rm -rf /通常需要写成rm -rf --no-preserve-root /或者写成rm -rf /*绕过保护。这里把它作为背景知识记下来后面的容器实验会用到。3. 容器隔离的真相它靠什么拦住死亡命令死亡命令之所以在容器里“变温柔”核心原因是容器并不是一台完整的操作系统而是宿主机内核之上的一个隔离运行环境。它主要由四类内核机制构成Namespace、cgroups、Capabilities 和分层文件系统。3.1 Namespace让容器只能看到自己Namespace 是 Linux 内核提供的一种资源隔离手段。它把进程看到的系统视图分割成不同空间每个命名空间里的进程只能看到该命名空间内的资源。Linux 容器主要使用以下几类 NamespacePID Namespace隔离进程编号容器内的 PID 1 是容器的 init 进程而不是宿主机的 systemd。Mount Namespace隔离挂载点视图容器内看到的/是它自己的根文件系统。UTS Namespace隔离主机名。IPC Namespace隔离进程间通信资源。Network Namespace隔离网络栈每个容器有自己的网卡和 IP 地址。User Namespace隔离用户 ID容器内的 root 可以映射为宿主机上的普通用户。当你启动一个 Docker 容器时Docker 会自动创建这些隔离空间。这就是为什么在容器里执行ps aux只能看到容器自己的进程执行mount也看不到宿主机的真实挂载点。3.2 cgroups给资源安装限速器Namespace 负责隔离资源视图cgroups 负责限制资源使用量。cgroups 可以限制进程组能够使用的 CPU、内存、磁盘 I/O 和进程数量。对应到 Docker 参数--memory对应内存限制。--cpus对应 CPU 限制。--pids-limit对应 PID 数量限制。对死亡命令实验来说--pids-limit尤其重要。fork 炸弹之所以能杀死一台主机是因为它不断创建新进程直到系统 PID 表耗尽。如果容器设置了 PID 上限fork 炸弹只能撑爆容器自身的进程额度而不会拖垮宿主机。3.3 Capabilities给 root 权限打折扣Linux 系统把 root 权限拆分成几十个细粒度权限项称为 Capabilities。Docker 在默认情况下并不会给容器内 root 赋予全部权限而是会丢弃危险项比如CAP_SYS_ADMIN、CAP_SYS_MODULE这类能直接操作内核和挂载文件系统的能力。这意味着即使容器里是 root 用户很多系统级操作依然会被拒绝。比如普通容器里执行mount通常会报Operation not permitted加载内核模块更会被直接拦截。3.4 分层文件系统镜像是模板可写层是草稿Docker 镜像由多层只读文件系统组成容器启动后会在镜像之上叠加一个可写层。使用 OverlayFS 时镜像层是 lowerdir容器可写层是 upperdir最终合并成容器内看到的根文件系统。这个机制解释了为什么容器里执行rm -rf /不会把宿主机文件删掉。删除操作只发生在可写层如果被删的文件来自镜像层Docker 会在可写层写入一个 whiteout 标记相当于把镜像层文件“遮住”但镜像层本身没有动。所以容器崩溃了重新用同一个镜像启动一个容器文件又是完好的。3.5 容器与虚拟机的安全边界差异维度虚拟机Docker 容器隔离级别硬件虚拟化内核级隔离内核每个虚拟机有独立内核所有容器共享宿主机内核启动速度分钟级秒级文件系统独立磁盘镜像镜像层 可写层默认安全边界较强依赖 Namespace、cgroups、Capabilities资源占用高低这段对比的核心结论是虚拟机拥有独立内核破坏虚拟机内的文件系统宿主机层面有硬边界保护容器共享宿主机内核边界由 Namespace 和 Capabilities 构建并没有虚拟机那么厚。如果内核出现漏洞或被显式授予了特权容器隔离就可能被穿透。4. 实验环境准备一个 Ubuntu 容器下面进入实操环节。实验环境建议使用一台可以随时重启的测试主机避免把风险带入生产环境。首先安装 Docker。在 Ubuntu 上最简单的方式是使用系统软件源sudo apt update sudo apt install -y docker.io docker-compose-v2 sudo systemctl enable --now docker sudo docker version如果主机配置较好也可以用 Docker 官方脚本安装最新版本curl -fsSL https://get.docker.com | sudo sh安装完成后拉取 Ubuntu 22.04 镜像docker pull ubuntu:22.04接下来启动一个用于实验的一次性容器。这里的关键是设置资源限制和安全参数让实验破坏力被限制在容器内部docker run -it --rm \ --name death-test \ --pids-limit 512 \ --memory 512m \ ubuntu:22.04 bash参数说明-it以交互模式进入容器。--rm容器退出后自动删除不残留实验现场。--pids-limit 512限制容器内最多只能创建 512 个进程防止 fork 炸弹波及宿主机。--memory 512m限制容器最多使用 512MB 内存。ubuntu:22.04基础镜像。进入容器后先确认环境和基础工具是否正常cat /etc/os-release ls / which apt-get正常情况下你会看到 Ubuntu 22.04 的系统信息根目录下存在bin、etc、usr、var等目录apt-get也能找到。这个容器就是下面的“死亡命令实验室”。5. 在 Ubuntu 容器里执行死亡命令现在开始逐个实验。请注意下面的命令全部只建议在一次性、加好资源限制的容器中执行不要在生产环境或任何有重要数据的 Linux 主机上复制。5.1 rm -rf /容器死了宿主机没事执行容器实验最核心的命令rm -rf --no-preserve-root /或者使用一个更常见的变体rm -rf /*命令执行后屏幕上会快速滑过大量Read-only file system和No such file or directory错误。这是因为/proc、/sys、/dev等特殊文件系统对容器是只读的或者删到中途已经找不到对应的文件。等命令停下来后再尝试一些基本操作ls / which bash apt-get update你大概率会看到bash: ls: command not found bash: which: command not found bash: apt-get: command not found原因是/usr/bin、/bin下的可执行文件已经被删除。此时 bash 进程本身还活着因为它启动时加载了对应的二进制文件文件描述符仍然持有已经删除的 inode但任何需要调用外部可执行文件的命令都会失败。你只能使用echo、exit这类 bash 内建命令。实验到这里容器实际上已经“废了”。退出容器exit因为启动时加了--rm容器会自动清理宿主机上不会留下这个容器的可写层。然后重新用同一个镜像启动一个新容器docker run -it --rm ubuntu:22.04 bash ls / which apt-get你会发现所有文件都在apt-get也完好无损。这就是分层文件系统的作用rm -rf /删除的是容器可写层视图镜像层依然存在。如果你没有加--rm而是让容器退出后重新docker start则会看到文件仍然处于被删除状态因为 whiteout 标记还留在可写层里。所以正确做法是删掉旧容器用原镜像重建。5.2 fork 炸弹不设 PID 上限会拖垮整个主机fork 炸弹最经典的形式是一行 Bash 代码:(){ :|: };:它的含义比较绕拆开看是:(){ ... }定义了一个名为:的函数。:|:在函数体内调用自己两次并用管道连接。表示把调用放到后台执行。:在函数定义完成后调用一次启动第一波递归。这样每次调用都会生成两个新进程两个新进程又会各自生成两个进程数量指数级增长直到系统资源耗尽。在刚才启动的容器里我们已经设置了--pids-limit 512所以在容器内执行:(){ :|: };:你会看到大量输出bash: fork: Resource temporarily unavailable这说明进程创建已经被 cgroups 拦住了。容器内的 PID 数量达到 512 上限后fork 失败宿主机进程创建不受影响。这个实验非常直观地展示了 cgroups 的价值。但如果你启动容器时忘了加--pids-limit在容器内执行同样的 fork 炸弹后果会严重得多。因为所有容器共享宿主机的 PID 表fork 炸弹会持续创建进程直到宿主机无法创建新进程严重时整个主机失去响应只能重启。所以这里再次强调做资源型死亡命令实验--pids-limit和--memory是保命符。5.3 mkfs 与 dd设备节点没映射进来命令就无的放矢mkfs.ext4 /dev/sda和dd if/dev/zero of/dev/sda是操作块设备的死亡命令。在物理机上它们会直接格式化磁盘或覆盖磁盘数据。在普通容器里执行这一条看看ls /dev/sd*在默认的 Docker 容器中你很可能看到这一行ls: cannot access /dev/sd*: No such file or directory原因是 Docker 默认不会把宿主机的磁盘设备节点传进容器。容器内/dev目录下只有 Docker 自己创建的基本设备节点比如/dev/null、/dev/zero、/dev/tty。没有/dev/sdamkfs和dd根本没有目标可操作。即使容器内有/dev/sda文件也不一定对应宿主机的真实磁盘。它可能是容器自己的虚拟设备节点。真正危险的是下面这类启动方式docker run -it --rm --device /dev/sda:/dev/sda ubuntu:22.04 bash或者docker run -it --rm --privileged ubuntu:22.04 bash这两种方式会把宿主机的真实磁盘设备暴露给容器。如果此时在容器里执行dd if/dev/zero of/dev/sda bs1M count10写入的就是宿主机磁盘扇区数据会直接损坏。这两条命令我不建议在任何环境中实际执行请把它当作安全警告来理解。5.4 chmod -R 777 /权限体系崩塌但只在容器内chmod -R 777 /会把根目录下所有文件的权限位改成rwxrwxrwx。在普通 Linux 主机上这意味着系统中的敏感文件比如/etc/shadow、SSH 私钥、sudo 配置全部向任意用户开放系统安全体系会瞬间崩塌。在容器里执行chmod -R 777 /输出中同样会夹杂大量Read-only file system错误因为/proc、/sys这类特殊文件系统对容器是只读的。但容器自己 rootfs 中绝大多数文件的权限会被改成 777。这时候容器里的很多服务会因为权限变化出现奇怪行为。比如 SSH、nginx 这类对配置文件权限敏感的程序可能直接拒绝启动。不过这个改动不会影响宿主机因为容器的文件系统是隔离的视图。重启一个新的 Ubuntu 容器权限马上恢复正常。这里值得注意的另一个点是chmod这类命令不像rm那样需要绕过保护它没有内建的根目录保护机制。所以在主机上执行这条命令也需要格外谨慎。5.5 mv / /dev/null大多数时候根本执行不了mv / /dev/null本身是一句流传很广的玩笑式死亡命令。直觉理解是把整个根目录移动到空设备/dev/null中让系统文件全部“消失”。但在 Linux 中/是根文件系统的挂载点。对一个正在使用的挂载点执行mv内核几乎会立即拒绝操作mv: cannot move / to /dev/null: Device or resource busy即使你通过某种方式让mv开始工作它也需要把整个根目录树复制到另一个文件系统再删除源目录。对于/proc、/sys这类伪文件系统mv根本无法处理。所以这条命令在绝大多数情况下只是“看起来厉害”实际并不会造成真正的物理机级伤害。6. 真正危险的场景隔离失效的边界上面这些实验证明普通容器对死亡命令有较强的隔离能力。但下面这些场景会直接击穿隔离边界值得每一位使用 Docker 的开发者警惕。6.1 挂载宿主机目录一条命令毁掉宿主机数据用-v参数把宿主机目录挂载进容器是 Docker 最常见的用法之一。但如果你把宿主机的重要目录以可写方式挂载进容器容器里的rm -rf就不再是“容器内删除”而是等价于在宿主机上执行删除。先做一个安全实验。在宿主机上创建一个测试目录mkdir -p ~/host-data echo this is important data ~/host-data/a.txt然后把它挂载进容器docker run -it --rm -v ~/host-data:/data ubuntu:22.04 bash进入容器后执行删除