沙盒（Sandbox）的本意是给不可信代码划一块隔离的活动范围，让它无论怎么折腾都碰不到宿主系统的核心资源。但现实往往事与愿违：一旦沙箱的隔离边界出现裂缝，攻击者就能从受限环境跳到宿主机上，这个过程就是沙盒逃逸。逃逸成功后，攻击者拿到的权限可能远超沙箱设计时的预期，轻则读取敏感文件，重则控制整个宿主机。本文围绕逃逸发生的原因，重点讲讲权限控制与监控这两道防线该怎么搭建。
沙盒逃逸的常见攻击路径
要防住逃逸，先得理解攻击者从哪里下手。归纳起来，常见的逃逸路径主要有三类。第一类是不安全的系统调用暴露。沙箱本质上是对进程行为的一种约束，如果实现沙箱时没有过滤掉危险的系统调用，攻击者就可以利用这些调用直接与内核交互。比如历史上多次被利用的ptrace、process_vm_readv等调用，都曾成为逃逸的跳板。
第二类是共享内核带来的漏洞面。无论是Docker容器还是浏览器的渲染进程，大多数沙箱方案并没有独立内核，沙箱内外共用同一个Linux内核。这意味着内核的任意漏洞都可能成为逃逸的通道。脏牛（CVE-2016-5195）这类提权漏洞就是典型例子：容器内的普通用户利用内核竞态条件直接获得宿主机root权限。
第三类是配置缺陷导致的特权过大。以容器为例，如果启动时挂载了Docker Socket、使用了--privileged参数，或者以root身份运行且没有丢弃多余的能力（capabilities），那么沙箱就形同虚设。下面这段命令是很多开发者图省事时写出来的典型反例：
# 危险写法：几乎放弃了所有隔离 docker run --privileged -v /var/run/docker.sock:/var/run/docker.sock \ -v /:/host --rm -it ubuntu bash # 挂载宿主机根目录意味着容器内可以直接改写宿主机文件
这条命令里，--privileged赋予容器几乎所有特权，挂载docker.sock等于让容器可以再启动任意容器，挂载根目录更是直接暴露宿主机文件系统。攻击者只要在容器内拿到执行权，就等于拿到了宿主机。
权限控制：把最小权限原则落到实处
权限控制是防逃逸的第一道防线，核心思路是最小权限原则：进程只拿到完成任务所必需的权限，多余的统统丢弃。在Linux上落地这个原则有几个具体手段。
第一是seccomp（secure computing mode）。seccomp可以给进程安装一个系统调用过滤器，白名单之外的调用直接被内核拒绝。Docker默认启用了seccomp并屏蔽了几十个高危调用，但如果你是自己实现沙箱（比如为插件系统、在线代码执行平台设计隔离层），就需要显式配置。看一下用libseccomp的C代码怎么写：
#include <seccomp.h>
#include <unistd.h>
int enable_seccomp(void) {
scmp_filter_ctx ctx;
// 默认动作：拒绝所有未明确允许的系统调用
ctx = seccomp_init(SCMP_ACT_KILL);
if (ctx == NULL) return -1;
// 逐一放行基础调用：读、写、退出
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
// 文件操作需要限定参数，这里放行只读打开
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(open), 1,
SCMP_CMP_A0(SCMP_CMP_MASKED_EQ, O_RDONLY, O_RDONLY));
// 加载过滤器，此后无法再修改
if (seccomp_load(ctx) < 0) return -1;
seccomp_release(ctx);
return 0;
}第二是Linux capabilities的裁剪。传统的root是全能的，而capabilities把root权限拆分成几十个细粒度的能力。运行容器时应该显式去掉CAP_SYS_ADMIN、CAP_SYS_PTRACE这类高危能力，只保留业务必需的。第三是强制访问控制（MAC），比如AppArmor和SELinux。它们从内核层面给进程画定了能访问哪些文件、能执行哪些操作的策略，即使进程被攻破也难以越界。Docker提供的默认AppArmor配置就已经拦截了大量已知逃逸手法。
此外还有几个容易被忽视的细节：容器内进程尽量用非root用户运行；不要把宿主机的敏感路径挂进容器；禁用不需要的内核模块加载；对需要特权的场景优先考虑rootless容器方案，让容器从一开始就运行在普通用户命名空间内。
运行时监控：让逃逸行为无所遁形
权限控制解决的是「能不能做」的问题，监控解决的则是「做没做」的发现问题。再严密的权限体系也可能被未知漏洞绕过，这时候运行时监控就是最后一道报警器。
监控的第一层是系统调用审计。Linux的audit子系统可以针对特定调用和参数记录日志，比如监控所有execve调用就能发现沙箱内进程是否在尝试执行计划外的二进制。更现代的方案是eBPF，它能在内核中安全地挂载探针，以极低开销采集进程行为。Falco这个开源工具就是基于类似思路，内置了大量规则，能直接检测「容器内启动shell」「读写宿主机敏感文件」「提权操作」等可疑行为：
# 启动Falco后，命中规则会输出类似告警 # 规则示例：容器内发起了提权 # 条件：container 字段非空 且 setuid 或 setgid 被调用 # 安装并运行 sudo falco # 典型告警输出 # 09:32:11.402145615: Warning Setuid or setgid (user root) # container_id=ab31f2... exe=/tmp/x command=cap_setuid
第二层是文件系统与网络行为的基线比对。沙箱内的正常业务行为通常是可预期的，哪些目录会被读写、会连哪些外部地址，都可以提前建立基线。一旦出现偏离，比如沙箱内进程突然尝试访问/etc/shadow或连接陌生的外网IP，就应该触发告警甚至自动终止进程。
第三层是日志的集中管理与关联分析。单台机器上的告警价值有限，把审计日志、容器事件、网络流量统一送到中心平台做关联，才能还原攻击链的全貌。实践中建议把告警直接对接到自动化处置：检测到逃逸特征时立即暂停容器、保留现场快照供后续取证，同时通知安全团队介入。
构建纵深防御的整体思路
单独依赖任何一项技术都无法彻底杜绝沙箱逃逸。权限控制降低攻击面，监控缩短发现时间，两者配合再加上定期的内核补丁更新、沙箱组件版本升级，才构成完整的纵深防御。给自己的系统做一次体检时，可以按这个顺序检查：容器是否以root运行、seccomp和MAC策略是否生效、挂载点有没有暴露敏感路径、运行时监控是否覆盖了高危行为。
最后要强调的是，沙箱的安全性是动态的。新的内核漏洞、新的绕过手法会不断出现，防御策略也需要跟着演进。把权限收敛到最小、让每一次越界行为都能被看见，这两件事做到了，沙箱逃逸的风险就能被控制在一个可接受的范围内。