1. 从一次线上事故说起：为什么执行沙箱隔离不是可选项
去年冬天，我接手了一个内部工具平台的维护工作。这个平台的核心功能是让用户提交一段脚本，由服务端执行后返回结果。听起来很常规，对吧？问题出在一个周五的傍晚——某位同事提交了一段带有递归删除逻辑的脚本，本意是清理自己临时目录下的测试文件，结果路径拼接出了偏差，直接把共享存储上近三个月的构建产物删了个干净。万幸的是有冷备份，恢复花了整整一夜。
这件事之后，我把整个执行链路重新梳理了一遍，核心结论只有一个：任何允许外部输入代码并执行的系统，都必须把执行环境关进笼子里。这个笼子，就是执行沙箱。
所谓执行沙箱隔离，说白了就是给不受信任的代码划一块"自留地"，让它在这块地里怎么折腾都行，但绝对碰不到外面的东西。它要解决的核心问题有三个：第一，文件系统隔离，不能让脚本随意读写宿主机的文件；第二，网络隔离，不能让脚本偷偷往外发数据或者扫描内网；第三，资源隔离，不能让一段死循环把CPU和内存吃干榨净，拖垮整个服务。
这篇文章适合谁看？如果你正在做在线代码评测、低代码平台的脚本引擎、自动化运维平台的任务执行模块，或者任何需要"跑别人写的代码"的系统，那这篇内容应该能帮你少走不少弯路。我会从隔离方案选型、具体实现、踩过的坑、性能取舍几个维度，把执行沙箱这件事讲透。文中涉及的工具和方案都是通用技术，你可以根据自己的技术栈灵活替换。
2. 隔离强度的三个档位：从"软隔离"到"硬隔离"的选型逻辑
2.1 为什么不能只用语言层面的限制
很多人第一反应是：我在代码层面做检查不就行了？比如禁止导入危险模块、过滤危险函数调用。这种做法我称之为"软隔离"，它的致命缺陷在于——你永远无法穷举所有绕过方式。
以Python为例，你禁用了os模块，但攻击者可以通过__import__动态导入；你禁用了__import__，还有importlib；你封了importlib，还有ctypes可以直接调系统调用。这是一场永远打不赢的军备竞赛。软隔离只能防君子，防不了有心人。所以我的原则是：软隔离可以作为第一道防线做快速拦截，但绝不能作为唯一防线。
2.2 三种主流隔离方案的横向对比
在实际项目中，我评估过三种方案，它们各有适用场景。下面这张表是我当时做的对比，直接贴出来供你参考：
| 隔离方案 | 隔离维度 | 启动速度 | 资源开销 | 适用场景 | 实现复杂度 |
|---|---|---|---|---|---|
| 进程级隔离 | 文件、网络、资源 | 毫秒级 | 低 | 可信度较高的内部脚本 | 低 |
| 容器级隔离 | 文件、网络、资源、进程 | 百毫秒级 | 中 | 多租户、不可信代码 | 中 |
| 虚拟机级隔离 | 全维度硬件级 | 秒级 | 高 | 高安全要求、强对抗场景 | 高 |
进程级隔离的核心思路是用独立的系统用户跑脚本，配合chroot或者命名空间做文件系统限制，再用ulimit限制资源。它的优点是快，缺点是隔离不够彻底，尤其是网络层面需要额外配合防火墙规则。
容器级隔离是我最终选择的方案。它利用Linux的namespace做视图隔离，用cgroup做资源限制，用seccomp做系统调用过滤，三层叠加之后，隔离强度足够应对绝大多数场景，同时启动速度还能接受。虚拟机级隔离虽然最安全，但每次执行都要起一个完整的操作系统，对于需要频繁执行脚本的平台来说，开销太大了。
2.3 选型时最容易忽略的一个维度：执行频率
选型的时候，大家容易盯着"安全性"这一个维度，但我踩过的坑告诉我，执行频率往往才是决定方案的关键变量。
如果你的平台一天只跑几十次脚本，那虚拟机方案完全可行，安全省心。但如果你的平台是代码评测系统，高峰期每秒要跑上百个提交，那虚拟机的启动开销就是灾难。这时候容器方案的优势就体现出来了——你可以预先启动一批"热容器"待命，任务来了直接投递进去执行，省去冷启动时间。
我当时做的测算：单次容器冷启动约300毫秒，预热池方案可以把有效启动延迟压到50毫秒以内。而虚拟机冷启动普遍在3秒以上，预热成本又太高。所以对于高频场景，容器方案几乎是唯一解。
3. 容器沙箱的落地实现：namespace、cgroup与seccomp的三层防线
3.1 文件系统隔离：让脚本只能看见"该看见的"
文件系统隔离是沙箱的第一道防线。核心目标是：脚本执行时，它看到的根目录是一个精心准备的、只包含必要依赖的最小文件系统，宿主机上的其他目录它一概看不见。
实现上，我用的是pivot_root配合挂载命名空间。具体做法是：先准备一个基础镜像目录，里面放好运行时需要的解释器、标准库、临时目录；然后在新进程的挂载命名空间里，把这个目录挂载为新的根，再用pivot_root切换过去。切换完成后，旧根被卸载，脚本就彻底看不到宿主机的文件系统了。
这里有个细节值得展开：临时目录的挂载方式。脚本执行过程中难免要写临时文件，如果直接写在容器可写层，一是会污染镜像，二是多个任务之间可能互相干扰。我的做法是给每个任务单独挂载一个tmpfs到/tmp，大小限制在64MB，任务结束自动销毁。这样既保证了隔离，又避免了磁盘I/O成为瓶颈。
还有一个容易忽略的点：只读挂载。除了/tmp之外，其他所有目录我都用只读方式挂载。这样即使脚本试图修改系统文件，也会直接失败，而不是悄悄改坏了环境影响后续任务。
3.2 资源限制：cgroup的两个关键参数
资源隔离靠的是cgroup。我重点配置两个维度：CPU和内存。
CPU方面，我用cpu.max限制配额。比如设置成50000 100000，意思是每100毫秒的周期内最多使用50毫秒的CPU时间，相当于半个核心。这样即使脚本里写了死循环，它也只能吃掉半个核心，不会把整台机器拖垮。
内存方面，用memory.max设置硬上限，比如256MB。超过这个值，内核会直接触发OOM killer把进程干掉。这里有个坑：内存限制要留足余量。我一开始设了128MB，结果很多正常的Python脚本因为加载标准库就超了，频繁被误杀。后来调整到256MB，误杀率大幅下降。经验值是：在你实测正常脚本峰值内存的基础上，乘以1.5到2倍作为上限。
另外，memory.swap.max建议设为0，禁止使用交换分区。因为一旦允许swap，内存限制就形同虚设，脚本可以把内存压力转移到磁盘上，拖慢整台机器。
3.3 系统调用过滤：seccomp白名单的正确打开方式
seccomp是容器沙箱里最容易被低估的一层。它的作用是限制进程能调用哪些系统调用。默认情况下，容器里的进程可以调用几百个系统调用，其中很多对于执行脚本来说根本用不上，但恰恰是攻击者喜欢的入口。
我的策略是白名单模式：只放行脚本执行必需的系统调用，其余一律拒绝。一个典型的Python脚本执行需要的系统调用大概包括：read、write、openat、close、fstat、mmap、mprotect、brk、exit_group、rt_sigreturn等几十个。像socket、connect、mount、ptrace这些危险调用，直接拒绝。
配置seccomp有个实用技巧：先用审计模式跑一段时间。不要一上来就开拦截模式，而是先记录所有被调用的系统调用，跑一批典型脚本，收集出完整的调用集合，再基于这个集合生成白名单。这样能避免因为漏掉某个必要调用导致脚本莫名其妙失败。
注意：seccomp规则一旦生效，违反规则的进程会收到SIGSYS信号直接终止。调试阶段建议先用
SCMP_ACT_LOG模式记录而不拦截，确认白名单完整后再切换到SCMP_ACT_ERRNO模式。
4. 网络隔离的实操细节：不只是"断网"那么简单
4.1 默认拒绝，按需放行
网络隔离的基本原则是默认拒绝所有出站连接。实现方式很简单：把容器加入一个独立的网络命名空间，这个命名空间里没有配置默认路由，也没有DNS服务器。脚本尝试发起网络请求时，会直接失败。
但实际业务中，总有一些场景需要网络。比如脚本需要调用内部某个API获取数据。这时候就需要按需放行。我的做法是维护一个白名单，只允许访问特定的IP和端口。实现上可以用iptables规则，也可以用更轻量的方式——在容器网络命名空间里只保留一条指向特定目标的路由。
这里要特别提醒：千万不要图省事直接给容器配置宿主机的网络。我见过有团队为了调试方便，直接用--network host模式跑脚本，这等于网络隔离完全失效，脚本可以直接访问内网所有服务，风险极高。
4.2 DNS是个隐蔽的泄漏通道
即使你禁用了网络连接，DNS查询也可能成为信息泄漏的通道。攻击者可以通过构造特定的域名查询，把数据编码在域名里发出去。虽然这种攻击需要外部有接收端配合，但在高安全要求的场景下不得不防。
我的处理方式是：在容器的网络命名空间里，把/etc/resolv.conf指向一个不存在的地址，或者直接挂载一个空的配置文件。这样任何DNS查询都会立即失败，堵死这条通道。
4.3 出站流量的审计与限速
对于确实需要放行网络的场景，我建议加上审计和限速。审计方面，记录所有出站连接的目标地址和端口，便于事后追溯。限速方面，用tc命令对网络接口做带宽限制，防止脚本通过大量请求对外发起攻击。
这块的配置相对复杂，如果你的场景对网络需求不高，我建议直接全禁，省心又安全。只有在业务确实需要时才开启白名单，并且白名单要尽可能窄。
5. 那些让我熬夜排查的坑：沙箱落地过程中的真实问题
5.1 文件描述符泄漏导致的"幽灵进程"
沙箱上线初期，我遇到一个诡异现象：运行一段时间后，宿主机上会积累大量僵尸进程，而且容器的清理逻辑偶尔会失败。排查了很久才发现，问题出在文件描述符继承上。
父进程在创建容器时打开的一些文件描述符，被意外继承到了容器内的脚本进程中。脚本执行结束后，这些描述符没有正确关闭，导致容器无法完全销毁。解决方案是在创建容器进程时，对所有不需要的文件描述符设置close-on-exec标志，确保它们不会被子进程继承。
这个坑的教训是：沙箱的清理逻辑必须做幂等设计。不能假设每次清理都能一次成功，要有重试机制和兜底清理。我后来加了一个定时任务，每隔几分钟扫描一次残留的容器和进程，强制清理超时未销毁的资源。
5.2 时间片耗尽引发的"假死"
另一个让我头疼的问题是脚本"假死"。现象是脚本提交后一直不返回结果，但CPU和内存占用都很低，看起来不像死循环。后来定位到是CPU配额设置过小导致的。
当时我把CPU配额设成了10000 100000，也就是10%的核心。对于计算密集型的脚本，这个配额太小，脚本大部分时间都在等待CPU时间片，执行速度极慢，看起来就像卡死了。调整到50%之后问题消失。
这里的经验是：CPU配额要根据脚本类型动态调整。对于I/O密集型脚本，低配额没问题；对于计算密集型脚本，配额不能太低。我后来的做法是提供几个档位，让提交者自己选择，默认给中间档。
5.3 镜像层缓存带来的"脏环境"
容器镜像的层缓存机制在构建时很方便，但在沙箱场景下可能带来问题。有一次我发现，某个脚本执行后留下的临时文件，竟然出现在了后续脚本的执行环境里。排查后发现是镜像构建时的缓存层没有正确清理。
解决方案是：每次执行都基于一个干净的只读基础层，所有写操作都发生在临时的可写层。任务结束后，可写层直接丢弃。这样从根本上杜绝了任务之间的环境污染。同时，基础镜像的构建要确保没有残留任何临时文件，构建完成后做一次完整性校验。
5.4 信号处理不当导致的资源残留
脚本被强制终止时，如果信号处理不当，可能留下残留资源。比如脚本创建了子进程，主进程被kill后子进程变成孤儿进程继续运行。
我的处理方式是：把容器内的主进程设为进程组的组长，终止时向整个进程组发送信号。同时配合cgroup的cgroup.kill接口，确保cgroup内的所有进程都被清理干净。这个细节在文档里往往不会强调，但实际运维中非常关键。
6. 性能与安全的平衡：预热池、超时控制与降级策略
6.1 预热池：把冷启动成本藏起来
容器冷启动的延迟在300毫秒左右，对于交互式场景来说，这个延迟用户能感知到。我的优化方案是维护一个预热容器池。
具体做法是：预先启动一批容器，让它们处于"待命"状态——已经完成了文件系统挂载、资源限制配置、seccomp规则加载，只等任务投递进来执行。任务到达时，从池中取出一个容器，注入脚本，执行，返回结果，然后销毁该容器并从池中补充新的。
池的大小需要根据并发量动态调整。我设置了一个水位线：当空闲容器少于3个时触发补充，补充到10个为止。这样既能应对突发流量，又不会浪费太多资源。
6.2 超时控制：多级超时机制
超时控制不能只设一个值。我的方案是三级超时：
- 软超时：比如30秒，到达后向脚本发送SIGTERM，给它一个优雅退出的机会。
- 硬超时：比如35秒，到达后发送SIGKILL，强制终止。
- 兜底超时：比如60秒，由外部的监控任务检查，如果容器还没销毁，直接强制清理。
三级超时的设计是为了应对不同情况：有些脚本捕获了SIGTERM想做清理，软超时给它时间；有些脚本完全不理信号，硬超时强制杀；还有些极端情况连硬超时都没生效（比如内核态卡死），兜底超时来收尾。
6.3 降级策略：当沙箱本身出问题时
沙箱系统本身也可能出故障。比如容器运行时无响应、资源耗尽无法创建新容器等。这时候需要有降级策略。
我的做法是：当沙箱不可用时，直接拒绝新的执行请求，返回明确的错误信息，而不是退化成"直接在宿主机上跑"。后者是极其危险的，等于沙箱形同虚设。宁可服务不可用，也不能让不受信任的代码在无保护的环境下执行。
同时，降级期间要触发告警，让运维人员尽快介入。恢复后要有健康检查，确认沙箱功能正常后再重新开放服务。
7. 写在最后：一些个人体会
执行沙箱隔离这件事，技术方案本身并不复杂，难的是持续保持警惕。我见过太多系统，上线时沙箱配置得好好的，后来为了"临时调试"开个口子，再后来口子越开越大，最后沙箱名存实亡。
我自己的做法是：把沙箱配置纳入代码管理，任何修改都要走评审流程；定期做渗透测试，主动尝试绕过沙箱；监控告警要覆盖沙箱的异常行为，比如脚本尝试访问网络、尝试提权等。
还有一点体会是：不要追求一步到位。我一开始想做一个完美方案，结果拖了很久没上线。后来改成迭代推进——先上进程级隔离挡住大部分风险，再逐步升级到容器级，最后补齐seccomp和网络隔离。每一步都能独立提供价值，风险也在可控范围内。
如果你正在做类似的事情，我的建议是从最简单的方案开始，先让隔离机制跑起来，再根据实际遇到的威胁模型逐步加固。安全是一个持续的过程，不是一次性的配置。
