安全沙箱这个词，这两年被问到的频率明显高了。以前它多半躺在安全团队的方案文档里，现在做在线代码评测的、做插件市场的、做文档解析的、做自动化构建的，甚至做大模型生成代码执行环境的，都会在方案评审会上被问一句：这段不可信的东西，你打算怎么隔离？说白了，安全沙箱就是一套把"来路不明的执行体"关进可控笼子里的隔离机制，让它在里面随便折腾，但出不了圈、掀不翻桌、死了也不连累别人。它解决的不是"这段代码有没有漏洞"，而是"就算它有漏洞、就算它就想干坏事，最坏能坏到什么程度"。这篇内容我打算按从业者的视角，把沙箱的技术底座、参数怎么定、规则怎么写、验证怎么测、坑在哪里，一层层拆开讲，适合正在做隔离方案选型的中高级开发和运维同学，也适合刚接触这一块、想把概念落到实操上的新人。

1. 为什么要做安全沙箱：先把问题定义清楚

1.1 从"信任边界"倒推隔离需求

任何隔离方案都不是凭空设计的，它一定是从一条信任边界倒推出来的。所谓信任边界，就是你系统里"谁说的话我敢直接信"和"谁说的话我得先掂量一下"之间的那条线。你自己写的配置、你自己编译进主程序的模块，通常在线的这一侧；用户上传的脚本、第三方提交的插件、抓取回来的富文本里夹带的宏、模型吐出来的一段待执行代码，在线的另一侧。这两侧的代码如果跑在同一个进程里、共享同一套权限、访问同一片文件系统，那这条边界就形同虚设——对方只要有一次越界，你这边全盘皆输。

我见过不少团队最初的写法是"用 try-catch 包一下"或者"加个超时，跑太久就掐掉"。这在边界清晰、代码可信的前提下确实够用，但它挡不住主动的恶意行为：一段代码可以故意申请几个 G 的内存、可以 fork 出一堆子进程把调度器拖垮、可以把你的配置文件改写掉、可以连出去把内网的结构摸一遍。这些操作在你的进程视角看来都是合法调用，捕获不到任何异常。沙箱要做的，是在操作系统这一层把"合法但危险"的能力直接抽走，而不是在应用层去猜对面想干什么。这个思路转换很关键：应用层的防护是"识别坏人"，沙箱的思路是"让所有人都没有做坏事的工具"，后者的可靠性高一个数量级，因为它不依赖你对攻击手法的预判。

再往下追一层，隔离其实是三个不同强度的动作叠在一起：视图隔离让进程看到的世界不是真的世界，它以为自己有独立的根目录、独立的进程号空间、独立的网络栈；能力裁剪让它即使想调用某个系统接口，内核也不给它这个口子；资源约束保证它就算什么都不干、只是死循环或者疯狂申请内存，也只能烧掉自己那一份配额。三者缺一不可，只有视图隔离没有能力裁剪，等于把犯人关进一间门没锁的房间；只有能力裁剪没有资源约束，等于锁了门但没限制他的饭量，最后是你先扛不住。

1.2 沙箱不是万能药：能力、开销、兼容性的三角取舍

做方案选型时最容易犯的错误，是把沙箱当成"越强越好"的东西。实际上隔离强度、性能开销、兼容性这三个维度互相拉扯，你几乎不可能同时拿满分。隔离强度上去了，往往意味着多一层内核或者多一次上下文切换，系统调用的延迟就上去了；为了压延迟做大量透传，攻击面又回来了；为了兼容现有程序把权限放宽，前两项努力全部白费。我在实际项目里踩过最典型的一个坑，是早期为了省事用了语言层面的解释器沙箱，规则写得很漂亮，结果业务方一个依赖原生扩展的库直接跑不起来，最后推倒重来换成进程级隔离，白白多花了两周。

所以第一步永远是问清楚：这段代码到底有多不可信，它能造成的最大损失是什么。如果只是内部同事写的表达式配置，出错顶多算错数，那语言级沙箱加上执行时长限制就够了；如果是外部开发者提交的插件，会碰到文件系统和网络，那必须上进程级甚至更强的隔离；如果是完全公开、任何人都能提交的代码评测场景，那就得假设对方是带着已知漏洞来打的，需要把内核攻击面也考虑进去。这个问题没有标准答案，但有标准的思考路径：先列清楚要保护什么资产（宿主文件、内网、其他租户的数据、宿主内核），再列出攻击者可能用的手段，最后选一个"能挡住主要手段、开销业务能接受"的方案，而不是选一个听起来最唬人的。

还有一类场景其实根本不需要沙箱，这点很多方案文档里不会写。如果你的执行体是纯数据驱动的，比如只做模板渲染、只做规则匹配，压根没有任意代码执行的能力，那加沙箱纯属自我感动，反而给运维增加了一堆复杂度。判断标准很简单：执行路径里有没有"用户能决定调用哪个函数"的环节。没有，就别上沙箱，把输入校验和长度限制做扎实比什么都强。

2. 安全沙箱的核心技术底座拆解

2.1 命名空间：让进程活在一个"假的世界"里

命名空间是这一切的地基，它的作用不是阻止进程做什么，而是欺骗进程的感知。一个进程通过系统调用去查自己的进程号、列出目录内容、看自己的网卡，内核会先看它属于哪个命名空间，然后只返回那个命名空间里的东西。目前常用的有七类：挂载（mount）、进程号（PID）、网络（net）、进程间通信（IPC）、主机名（UTS）、用户（user）、控制组（cgroup）。其中挂载和 PID 是最基础的两项，前者决定它能看到哪些文件，后者决定它能不能看到、能不能影响到外面的进程。

这里有一个非常关键的细节，值得单独拎出来讲：PID 命名空间里，沙箱内的第一个进程会被分配为 1 号，而这个 1 号进程在沙箱内拥有特殊地位，信号处理、孤儿进程收养都跟它有关。这意味着你在沙箱里跑的不能是一个"干活的业务进程"，而必须是一个专门做初始化的小程序，它负责拉起业务进程、转发信号、在业务进程退出后回收僵尸进程。我在早期实现里图省事，直接把业务进程当 1 号跑，结果业务进程崩了之后沙箱不退出，卡在那里变成僵尸，调度器一直以为任务还在跑。这个坑非常常见，后面讲实操会给出具体做法。

用户命名空间则是权限映射的关键。它允许你在沙箱内成为一个"看起来是 root"的用户，但这个 root 的所有操作，映射到宿主机上只是一个普通用户。这个设计的价值在于：很多程序在非 root 下会拒绝启动或者行为异常，用户命名空间让它们乖乖跑起来，同时真实权限依然被牢牢限制。但要注意，用户命名空间本身在历史上有过若干提权问题，一些发行版默认关闭或者限制了它的嵌套层数，上线前一定要在目标内核上实测，别只在开发机上验证。

网络命名空间这一块，很多人以为"新建一个 net namespace 就等于断网了"，这是个误解。新命名空间里默认只有一个 lo 回环接口，确实连不出去，但只要你在里面配了 veth 对、把它桥接到宿主机网桥，它立刻就能上网。所以断网这件事必须显式做：要么干脆不建任何对外接口，要么用防火墙规则把出站流量掐死。反过来，如果你确实需要让沙箱内访问某些白名单服务，那就得老老实实做出口管控，而不是指望命名空间自动帮你隔离。

2.2 系统调用过滤：把"能做的事"收窄成白名单

命名空间解决"看到什么"，系统调用过滤解决"能做什么"。它的核心是一套内核提供的过滤机制，允许你在进程启动时挂上一个字节码程序，之后这个进程每次发起系统调用，内核都会先跑一遍这个程序，根据返回值决定是放行、返回错误码、还是直接杀掉进程。程序能检查的是系统调用编号和最多六个寄存器参数，注意是参数的值本身，不是参数指向的内存内容——这一点极其重要，很多人第一反应是"我要检查这个文件路径是不是在允许目录内"，但在过滤器里你是拿不到那个字符串的，指针解引用这个动作在内核里做既危险又不被支持。所以路径校验要靠挂载命名空间来做，过滤器只负责"这个系统调用整体上允不允许"。

白名单和黑名单的选择上，我强烈建议白名单。黑名单的思路是"列出已知的危险调用然后禁掉"，问题是内核的系统调用有几百个，还随版本不断增加，你永远列不全，漏掉一个就是一条通道。白名单反过来，只放行程序确实需要的那些，剩下的默认拒绝，安全性高得多。代价是调试很痛苦，你经常会在日志里看到一堆"operation not permitted"，然后一个个去猜是哪个调用被拦了。

一个实用的做法是分阶段：开发调试期用返回错误码的动作，生产期再考虑更严格的处置。返回错误码的好处是程序不会立刻死，你能看到完整的错误栈，配合审计日志能准确定位缺哪个调用；直接杀进程虽然更安全，但排查起来是黑盒，你不知道它死在哪一步。我一般会在测试环境跑一轮全量业务用例，把被拦的调用全部收集起来，人工过一遍，确认哪些是真需要、哪些是程序在探测环境，然后再收紧。

还有一个必须配的开关是"禁止提权"。它的作用是让进程及其所有子进程，在执行新程序时无法获得比当前更高的权限，典型场景就是防止有人通过设置用户位的可执行文件拿到 root。这个开关几乎零成本，任何沙箱都应该打开，属于闭着眼睛也要加的配置。

2.3 资源配额：给每个笼子装上闸刀

视图和能力都管住了，还得管"吃多少"。一段代码哪怕什么坏事都不干，只是申请内存、创建线程、写文件，也足以把整台机器拖垮，这是最常见的"非恶意故障"。控制组的统一层级版本提供了几个关键闸门，我按重要性排一下：内存上限、进程数上限、CPU 带宽、磁盘写入量。内存上限里又分硬限和软限两个值，硬限是碰到了就直接触发回收失败并杀掉进程，软限是碰到了先触发回收、尽量压回线下但允许短时超一点。实际配置里我会把软限设在硬限的九成左右，给突发流量留一点缓冲，避免业务正常波动就被砍掉，同时硬限绝对不能省，那是最后一道保险。

进程数上限是最容易被忽略、但事故率最高的一个。一个 fork 炸弹几十毫秒就能把系统的进程表塞满，到时候你自己都登录不进去排查。这个值不能拍脑袋设成几百，得算：业务进程本身的常驻线程数，加上它可能派生的子进程数，再乘一个安全系数。我一般的算法是基线数量乘以二，再加二十的余量，宁可设紧一点让它报错，也不要设松了让它炸。

CPU 带宽的配置很多人看不懂那两个数字。它本质是"在一个周期内，这个组最多能用多少时间"，周期一般取 100 毫秒，配额填多少就是每 100 毫秒能用多少毫秒。想限制到单核的一半，配额就填 50。这里有个细节：这个限制是带宽限制不是优先级，超了就被强制休眠到下一个周期，所以对延迟敏感的短任务要谨慎设，设太紧会造成明显的毛刺。磁盘这块则要看文件系统支持，写入速率和 IOPS 都可以限，但只对直接落盘的写入有效，内存里的临时文件系统不受这个管，所以临时目录要么限制大小，要么直接放内存里并单独设上限。

2.4 隔离强度的分层选型

下面这张表是我这几年做选型时反复用的对照，放在这里方便直接对照自己的场景：

选型时我的经验是贴着需求选，往上留一档。比如公开代码评测，理论上进程级隔离够用，但如果你的平台会被大量针对性测试，往上选一档到用户态内核或微虚拟机，代价是启动慢一点、镜像大一点，换来的是内核漏洞也打不穿。反过来，内部工具类的插件系统，进程级完全够，非要上微虚拟机就是给自己找麻烦，冷启动那几百毫秒会让用户明显感觉到卡顿。

3. 从零搭一个可用的沙箱：完整实操流程

3.1 环境准备与前置检查

动手之前先确认内核能力，这一步别跳。检查三件事：统一层级的控制组是否已挂载并启用、用户命名空间是否允许非特权创建、调用过滤机制是否在内核配置里打开。这三项任何一项不满足，后面的步骤全是空中楼阁。检查命令我一般写成一个小脚本，部署时先跑一遍：

# 1. 确认控制组为统一层级（输出 cgroup2 才符合预期） stat -fc %T /sys/fs/cgroup # 2. 确认用户命名空间可用（输出非 0 即允许） cat /proc/sys/kernel/unprivileged_userns_clone 2>/dev/null || echo "该内核无此开关，通常默认允许" # 3. 确认调用过滤已编译进内核 grep -E "CONFIG_SECCOMP|CONFIG_SECCOMP_FILTER" /boot/config-$(uname -r)

脚本跑完如果发现控制组还是旧的混合层级，别急着改，先看这台机器上有没有别的业务在跑，切换层级会影响现有负载。稳妥的做法是准备一台干净的目标环境，从系统安装阶段就启用统一层级，验证通过后再考虑存量迁移。另外提醒一句，容器环境里做这件事要看宿主的配置，很多托管环境根本不允许你在里面再建命名空间，测出来的结论和真实机器上完全不一样，一定要在和生产同构的环境里验证。

3.2 用命令行快速验证一个最小沙箱

在写代码之前，先用现成的命令行工具跑通一遍，能帮你快速建立直觉。下面这条命令做的事情是：新建用户、PID、网络、挂载四类命名空间，把当前用户映射成沙箱内的 root，挂载一个独立的进程文件系统，然后执行一个 shell：

unshare \ --user --map-root-user \ --pid --fork \ --net \ --mount --mount-proc \ --uts \ /bin/bash

进去之后你可以立刻验证隔离效果：ps aux只能看到沙箱内的两个进程，ip addr只有一个回环接口，hostname随便改不影响外面，ls /proc看到的是新挂载的进程文件系统。这几个现象就是命名空间在起作用的直接证据，比看任何文档都直观。

注意--fork这个参数不能省，它保证 PID 命名空间里的 1 号进程是一个专门做初始化的父进程，shell 作为它的子进程运行。如果省掉它，shell 自己变成 1 号，退出时的回收逻辑会出问题。同理，--mount-proc也是必须的，不重新挂载/proc的话，你在沙箱里执行ps看到的还是宿主机的进程列表，视图隔离等于没做。

3.3 构造一个只读的文件系统视图

文件系统是这类沙箱里最容易被攻破的一环，因为绝大多数逃逸手法最终都要落到"能写某个文件"或者"能挂载某个东西"上。我的做法是从零拼一个极简的根目录，而不是把宿主的整个根目录挂进去再挑着删。思路是：新建一个空目录作为新的根，然后把运行所需的最小集合以只读方式绑定进去，包括可执行文件目录、库目录、必要的设备文件，再单独给临时目录挂一个带限制的内存文件系统。

# 假设 $ROOT 是新根目录 mkdir -p "$ROOT"/{bin,lib,lib64,tmp,dev,proc} mount --bind -o ro /bin "$ROOT/bin" mount --bind -o ro /lib "$ROOT/lib" mount --bind -o ro /lib64 "$ROOT/lib64" # 临时目录：内存文件系统，且禁止执行、禁止设备文件、禁止设置用户位 mount -t tmpfs -o size=64m,nosuid,nodev,noexec tmpfs "$ROOT/tmp" # 设备目录只挂必需的两个，不挂整个 /dev touch "$ROOT/dev/null" mount --bind /dev/null "$ROOT/dev/null" mount --bind /dev/urandom "$ROOT/dev/urandom"

那三个挂载选项值得展开说。nosuid防止用户位生效，堵掉提权路径；nodev防止在里面创建设备节点，否则有人可以造一个指向物理磁盘的设备文件直接读盘；noexec防止把恶意程序写到临时目录再执行。这三个选项在临时目录上是标配，别嫌麻烦。至于把/dev整个挂进去，那是自找麻烦——里面有一堆设备节点，没必要也不安全。

切换到新根目录我用的是pivot_root而不是老的chroot。原因很实际：chroot只改当前进程的根路径记录，如果进程持有旧根目录的文件描述符，或者有能力再执行一次chroot，是可以"跳出去"的；pivot_root是把整个挂载树换掉，旧根被移到新位置并可以卸载，逃逸难度完全不是一个量级。切换前记得先chdir到新根目录内部，切换后把旧根卸载掉，这两步都不能漏掉。

3.4 落地调用过滤规则

规则写法上，我用的是 JSON 描述加生成器的方式，便于版本管理和审阅。下面是一个精简版示例，只保留结构，实际放行的调用会多得多：

{ "defaultAction": "SCMP_ACT_ERRNO", "architectures": ["SCMP_ARCH_X86_64"], "syscalls": [ { "names": ["read", "write", "close", "fstat", "mmap", "mprotect", "munmap", "brk", "exit_group", "rt_sigreturn"], "action": "SCMP_ACT_ALLOW" }, { "names": ["openat", "newfstatat", "readlinkat"], "action": "SCMP_ACT_ALLOW" }, { "names": ["clone", "execve"], "action": "SCMP_ACT_ALLOW", "comment": "仅第一阶段放行，收紧前务必确认业务确实需要" } ] }

defaultAction设成返回错误，意味着没列出来的调用一律拿不到，这是白名单的骨架。这里我特意把clone和execve单独拎出来加了注释，因为这两个是最需要审慎的：clone能造新进程，execve能执行任意程序，一个真正严格的沙箱应该只允许执行白名单内的二进制，甚至在业务运行起来之后就把execve彻底关掉——很多设计方案里有个"执行阶段切换"的动作，第一阶段要拉业务进程所以放行，进入业务逻辑后立刻把过滤器收得更紧，这个技巧非常实用，能大幅压缩可用攻击面。

调试期的做法我一般是把defaultAction临时改成记录日志，或者返回错误但不杀进程，然后拿一批真实业务用例去跑，把审计日志里被拦的调用名全部提取出来，人工过一遍。人工过这一遍不能偷懒，因为你会看到一些明显是程序在"探测环境"的调用，比如查询硬件信息、探测某个文件是否存在，这些一律不放行；也会看到一些真正需要的，比如时间相关的调用，那就放行。每放行一个调用，都问一句"它最坏能干什么"，答不上来的就别放。

3.5 资源配额参数怎么算

配额这块最忌拍脑袋，我给一套可以直接照着推的算法。先测业务基线：让业务在正常负载下跑一批典型任务，记录峰值内存、常驻线程数、CPU 使用率、写入量。假设测出来峰值内存 180MB、常驻线程 12 个、单任务 CPU 时间 800 毫秒。

内存硬限按峰值乘 1.5 取整，180 × 1.5 = 270，取 288MB（能被页大小整除，看起来也整齐）；软限取硬限的九成，约 256MB。这个组合的意思是：到 256MB 开始触发回收、压一压，还能继续跑；到 288MB 就无商量直接终止。进程数上限按常驻线程乘以二加二十，12 × 2 + 20 = 44，我一般直接取 64，留点余量但绝不给到几百。CPU 配额按"单核的百分比"算，如果这个任务应该占半个核，周期 100 毫秒配额就是 50；但如果它本身是短任务、对延迟敏感，我会把配额设到 100 甚至 200，只在并发上做控制，因为带宽限制造成的毛刺比并发排队更难受。

配置写入的语法按统一层级的接口来，注意软限的字段名不是直接叫"软限"，而是另一层语义，写错了不会报错但行为不对：

CG=/sys/fs/cgroup/sandbox-demo mkdir -p "$CG" echo 288M > "$CG/memory.max" echo 256M > "$CG/memory.high" echo 64 > "$CG/pids.max" echo "50000 100000" > "$CG/cpu.max" # 每 100ms 最多用 50ms，即半个核 echo "max" > "$CG/memory.swap.max"

最后那行 swap 上限我特意设成max的意思是不允许换出（不同版本语义略有差异，务必实测确认）。不允许换出的理由是：一旦允许换出，内存超限的进程不会被立刻杀掉，而是把宿主机的磁盘拖到疯狂读写，表现是整个机器卡死，比直接杀掉难受得多。

3.6 验证沙箱是否真的有效

规则写完必须实测，而且要用"攻击视角"去测，不能只跑通业务用例就算完。我整理了一份必测清单，每次上线前逐项过：

跑完这张表你会发现一个规律：大多数失败都发生在"没想到要测"的那一项上。我自己就漏测过内核信息泄漏那项，测试同学随手一读就把宿主机的很多信息摸出来了，虽然不足以直接逃逸，但信息量给得太多了，后来把相关路径整个屏蔽掉才算过关。测试清单这东西不怕多，怕的是你以为已经覆盖了。

4. 常见问题与排查实录

4.1 典型故障速查表

下面这些是我在实际部署里高频遇到的，按现象整理，方便对着查：

表格里最值得多说一句的是"内存明明没超却被杀"。统一层级的控制组在统计内存时会把页缓存也算进组内，如果你的业务大量读写文件，缓存会迅速把额度顶满，然后触发回收甚至终止。解决办法不是简单调大上限，而是先看事件统计里的具体计数，判断是匿名内存超了还是缓存压力导致的回收失败，前者要调额度，后者要限制写入速率或者主动丢弃缓存。这两种情况的处置方向完全相反，搞错了就是白折腾。

4.2 逃逸风险与加固清单

共享内核的方案有个天生的弱点：内核的攻击面就是所有沙箱共享的攻击面。一个内核漏洞被利用，影响的不是某一个沙箱，而是同一台机器上的全部。所以加固要分两层做，一层是沙箱本身的配置，一层是宿主机的纵深防御。

沙箱这一层，我认为必做的有四条。第一，调用过滤的白名单要真的白，运行阶段不需要的调用坚决不放，尤其是那几个能改变进程属性、能操作内存映射、能加载内核模块的调用，一个都不能留。第二，永远不要给沙箱内的进程任何额外能力，需要的就明确列出来，不需要的默认全部丢弃，这个"默认丢弃"比"逐个禁用"可靠得多。第三，禁止提权的开关必须打开，成本为零收益巨大。第四，敏感路径不要暴露，包括内核符号表、调试接口、宿主机的进程信息、控制组的挂载点，这些不是"直接可用"的漏洞，但会给攻击者省下大量侦察时间。

宿主机这一层，我的经验是三层叠加：强制访问控制策略用来兜底，即使沙箱配置出了问题，策略还能拦一道；及时更新内核，这是唯一能真正解决内核漏洞的手段，没有替代品；审计日志一定要留存且可追溯，出事之后能不能定位到具体的沙箱、具体的调用，全靠它。日志这块很多人只记了启动和退出，中间的调用被拦记录一点没有，一旦出问题就是两眼一抹黑。

还有一个容易被忽视的点：沙箱的配置本身要当成代码来管理。我见过把过滤规则直接硬编码在启动脚本里的，改一次要重新发版，最后没人敢改，规则烂在那里。正确做法是把规则抽成独立的配置文件，进版本库，走评审，每次变更都记录原因。这套流程看起来重，但真出事的时候，你能说清楚"为什么这个调用被放行了"，这个价值无法估量。

4.3 性能损耗的实测数字与调优

性能这块我不喜欢讲虚的，直接说实测感受。进程级方案里，命名空间创建本身的开销很小，主要成本在挂载操作和进程初始化上，一个极简根目录的启动耗时在几十毫秒量级，如果不做预热、每次都重新拼挂载树，会到一两百毫秒。优化手段很朴素：把根目录的挂载树预先构建好，做成模板，启动时只做一次绑定和切换，能把这部分压到十毫秒以内。

调用过滤的开销跟规则复杂度直接相关。规则简单、判断分支少的时候，单次调用额外开销在微秒以内，业务基本感知不到；但如果规则写了几百条、还带大量参数比较，那在调用密集的场景里（比如大量小文件读写）会有可观测的下降。我实测过一个偏极端的例子，一个每秒几十万次调用的场景，加规则前后吞吐差了大概百分之十几，后来把规则按调用频率排序、高频的放前面，差距缩到百分之五以内。这是个很实用的技巧：过滤器是顺序匹配的，热路径往前放。

真正的性能大头往往不在沙箱本身，而在资源限制带来的副作用。CPU 配额设太紧会造成周期性停顿，内存上限设太紧会频繁触发回收，这两项加起来对长尾延迟的影响远大于隔离机制本身。调优的顺序应该是：先放开配额跑出真实基线，再逐步收紧到刚好不触发限制，最后留百分之二十到三十的余量。反过来先设紧了再往上放，你会一直以为"沙箱就是慢"，实际上是参数没调对。

5. 落地场景与边界把控

5.1 几个典型场景的差异化做法

在线代码评测是最经典的场景，特点是代码完全不可信、任务短、并发高。这种场景下我最看重的是启动速度和回收的确定性，所以会选进程级或者微虚拟机里启动最快的那一档，把根目录做成只读模板复用，临时目录每次重建，超时和资源上限设得偏紧，宁可误杀不可放过。同时评测这种场景要特别注意输出量的限制，我遇到过一次，评测程序往标准输出狂打日志，把宿主的磁盘写满了，从那以后所有沙箱的标准输出都做了截断。

插件系统就不一样了，插件需要访问宿主提供的宿主能力，比如读某个配置、调用某个接口，这些能力必须通过明确的接口暴露，而不是把整个文件系统或网络都放开。我的做法是给每个插件分配一个独立的沙箱，能力通过一个受控的通信通道传递，通道上做参数校验和速率限制。这里的难点是插件往往需要持久化状态，那就得给它一个专属的可写目录，这个目录要单独做配额，而且绝对不能和宿主的配置目录有任何路径重叠。

文档解析和格式转换这类场景经常被低估。大家觉得"就是个文件解析，能有什么危险"，但解析器本身是极其复杂的代码，历史上出过的问题一点不少。这种场景的沙箱配置重点是：解析进程绝对不能有网络出口，因为解析一个文件不需要联网；临时目录要限额；输入文件要以只读方式传入；整个解析过程要有硬超时。我一般还会加一条，解析出来的外部链接一律不主动访问，避免被诱导去探测内网。

自动化构建场景的特点是任务重、耗时长的、依赖多。这时候沙箱的隔离强度要够，但资源上限不能设太紧，否则正常的编译任务都跑不完。我的经验是给构建沙箱单独一套配额模板，内存按依赖规模动态分配，缓存目录单独挂载并允许写，但要限总量。另外构建场景往往需要拉取外部依赖，网络出口就不得不开，这时候就得靠出口白名单来做管控，而不是简单断网。

5.2 沙箱之外还必须配的东西

有一点必须讲清楚：沙箱是最后一道防线，不是唯一一道。它管的是"跑起来之后出不了圈"，但代码怎么进来、结果怎么出去，这些环节它管不了。所以在沙箱之外，至少还要配三样东西。

第一是入口校验。上传的代码、提交的插件、传入的文件，在进沙箱之前先做一遍格式检查、大小限制、编码校验。这一步能把大量低级攻击挡在外面，成本极低。第二是超时与熔断。沙箱内的任务必须有一个硬性的总时长上限，超过就直接终止，不能指望任务自己退出。这个上限要包含沙箱启动、任务执行、结果回收的全过程，只算执行时间是不够的。第三是审计与追溯。每次沙箱任务的启动参数、资源使用、被拦调用、退出原因都要记录，且要能按任务标识查回来。出问题的时候，这份记录是你唯一的事实依据。

还有一条经验之谈：不要试图用沙箱去解决权限设计的问题。如果你的系统本身权限模型是乱的，谁都有一堆不该有的权限，那加多少层沙箱都是在给一个烂地基刷漆。先把权限收干净，再谈隔离，顺序不能反。

刚接触这块的时候，我总觉得隔离做得越狠越安全，恨不得每个函数调用都隔一层。做了几年下来，感受正好相反：好的隔离方案是让人感觉不到它的存在，业务方按正常方式写代码，出了事被兜住，这就够了。过度隔离带来的直接后果是没人愿意用，大家会想办法绕过去，最后你精心设计的方案变成一纸空文。所以每次评审方案，我都会问一句：这套东西上线之后，业务方接入需要改多少代码？如果答案是"要大改"，那这方案大概率活不过三个月。

另一个体会是参数一定要留出观测手段。我现在的习惯是，任何一项限制上线之前，先确认它的触发次数能不能被看到。看不到触发次数的限制，等于没有限制——你不知道它到底在保护你，还是在误伤业务。这个习惯是从一次事故里学来的：当时内存上限设得太紧，一批正常任务被静默杀掉，因为没有采集限制触发的事件计数，硬是查了两天才定位到。从那以后，我要求每一条限制都必须能回答三个问题：触发了几次、什么时候触发的、触发时任务的标识是什么，答不上来就不许上线。