两年前我第一次拿到一个大模型生成的 shell 脚本时第一反应是真的可以直接跑吗那脚本逻辑很漂亮把一堆日志文件按日期归档、压缩、清理读起来挑不出毛病。但就是因为太漂亮了反而不敢跑——它用了rm -rf虽然路径是/tmp/logs开头可谁知道模型在别处学来的习惯会不会顺手把变量没赋值的情况也妥善处理了。后来我把那脚本放在一个一次性容器里执行跑了十分钟确认无异常才落到真实环境。这其实就是大模型应用落地时最微妙的一环模型能生成代码不等于你能让代码安全地跑起来。OpenSandbox 解决的就是让大模型安全地执行代码这个问题——在模型和真实系统之间加一层可丢弃的隔离沙箱代码在受控环境里执行结果拿走副作用留在盒子里。做 AI 编程助手、智能体、自动化平台、开发工具的同学基本都会踩到这个需求。1. 大模型写代码的最后一道坎能生成不等于能执行1.1 那段让我后背发凉的代码有一次我让模型生成一个批量重命名图片的 Python 脚本它输出得很快正则写得很优雅。正当我准备复制到终端时多看了一眼里面调用了一个在线图片处理服务用os.system执行拼接出来的命令其中一半参数是从图片文件名里直接提取的。文件名里如果有分号或者命令行就不知道被拼成什么了。这不是模型作恶是它在海量代码里学到了很多人的坏习惯然后用一种恰好看起来很正常的组合输出给你。模型生成的代码本身是一串文本文本本身没有权限但一旦交给解释器执行它就有了你那台机器的权限。它能读你~/.ssh/id_rsa能访问你在~/.aws/credentials里的密钥能把.env文件内容打包发到任意地址。最麻烦的是这种风险完全不可预测——你没法通过多加一轮检验提示词来消除因为问题不在模型的理解能力而在它生成的东西本质上是从概率分布里采样出来的不是从安全定理里推导出来的。1.2 为什么让模型代码跑起来开始变成基础设施需求早期大家用大模型写代码都是生成完人工检查、人工执行最多再用 IDE 插件做个语法提示。但随着智能体Agent普及执行环节从人变成了程序智能体自己决定调用什么工具、生成什么命令、执行什么操作。如果每步都要人审批那智能体就失去了自动的意义如果不审批那平台就必须在底层提供一个能兜住所有风险的执行环境。另一个推动力是平台化。当代码执行能力对外开放比如做数据分析平台、自动化工作流工具用户提交的往往不是已在本地验证过的代码而是从模型对话里复制过来的、没有经过任何审查的代码。这些代码要在你提供的服务器上跑跑出结果给用户看但出了事故要平台背锅。这时候如果底层没有一个强沙箱产品根本不敢上线。1.3 三种常见执行方式的收益与风险对比执行方式部署成本隔离强度适用场景最大风险本机直接执行零成本无隔离个人验证、一次性脚本系统文件被删、密钥泄露普通 Docker 容器中中共享内核可信代码隔离容器逃逸、资源耗尽波及宿主机OpenSandbox 沙箱中高高多层叠加模型生成代码、不可信代码需要额外维护学习成本普通容器起到的隔离本质上是把进程关进了一个视野受限的房间但房间的墙是共享的同一面内核墙。如果恶意代码利用内核漏洞或者挂载配置失误仍然能穿透。OpenSandbox 的设计出发点就是默认所有代码都不值得信任隔离必须分层任何一层都不能作为唯一依赖。2. OpenSandbox 的分层隔离设计进程、文件、网络三道闸门2.1 第一层用 namespace 把进程装进盒子沙箱创建时第一件事是为目标代码准备一个隔离的进程视图。通过 Linux namespace 隔离 PID、挂载点、网络、主机名、IPC 和用户 ID让沙箱里的进程看不到宿主机的其他进程也看不到宿主机真实文件系统。关键是用户命名空间user namespace的映射把容器内 root 映射成宿主机上的普通用户这样即使沙箱代码拿到 root 权限在宿主机上也只是无特权用户。这里有一个很容易被忽略的小点PID namespace 隔离后沙箱内看到的PID 1并不是宿主机 init 进程而是沙箱自己的入口进程。但反过来沙箱外的进程是可以看到内部进程的因为外部视角是完整的层级视图。所以隔离从来都是相对的。真正的兜底要靠在宿主机侧用 cgroups 和 seccomp 建制而不是单纯依赖 namespace 的看不见。2.2 第二层只读根文件系统与临时可写区代码要跑必然依赖解释器和系统库但绝对不能让它改系统库。OpenSandbox 的做法是根文件系统整体以只读方式挂载所有依赖在构建镜像阶段就固化进去。容器内唯一可写的是挂载为 tmpfs 的/tmp和/workspace并且这两个目录也有独立的容量配额。为什么要刻意区分只读系统区和可写工作区因为模型生成的代码经常需要写临时文件、缓存数据但它的业务逻辑大概率不涉及修改系统配置。一旦工作区就是写入边界代码本身没有能力扩大这个边界恶意行为就被限制在可清理的临时空间里。这个设计思路和手机 App 的沙盒存储是同一个道理你可以随便往自己文件夹里堆东西但碰不到别的 App 的文件。2.3 第三层网络白名单与流量出口代理几乎所有真实的恶意行为都会依赖网络外传数据、下载恶意负载、建立反向连接。OpenSandbox 默认禁止沙箱直接联网只允许通过一个前置 HTTP 代理访问白名单内的域名或 IP。代码产生的 DNS 查询会被自定义解析器接管不在名单里的域名直接返回 NXDOMAIN连接直接失败。代理层同时承担协议净化的作用只放行 HTTP/HTTPS 请求过滤掉非标准协议的原始 TCP/UDP 流量这样常见的 DNS 隧道、自定义协议反弹连接就被直接切断了。实测中九成以上模型生成的代码只需要访问少数几个公开 API白名单机制极少产生误伤。2.4 资源配额cpu、memory、pids 三件套如果说三层隔离决定代码能干什么资源配额决定代码能干多久、用多少。OpenSandbox 对每个执行实例配置三组硬限制CPU通过 cgroup 的cpu.max限制比如最多使用 1 核的 80%防止恶意的密集计算挤占宿主机。内存限制总量和可回收阈值超限直接触发 OOM 杀掉。进程数pids.max限制最大并发进程/线程数。很多人只限制 CPU 和内存忘了 pids。没有 pids 限制时几行while(1){fork()}就能把宿主机的 PID 表打满即使每个进程都不耗 CPU整个系统也会因为无法创建新进程而瘫痪。这类攻击的成本极低、杀伤力极大pids 限制是必须加的。3. 威胁模型拆解真正要防的是哪几类妖魔鬼怪3.1 文件逃逸与敏感目录探测沙箱里最经典的一类攻击是文件系统逃逸。恶意代码或者被恶意诱导的代码会尝试越过工作区的边界去读宿主机敏感文件。常见手法包括路径穿越../../etc/passwd、符号链接指向挂载边界外部、直接枚举/proc、/sys等内核信息目录。OpenSandbox 的防线不只是一个只读根文件系统还有一个挂载点校验逻辑沙箱启动后会流检查容器内所有挂载点确保没有任何一个挂载点指向宿主机目录并且禁止在运行时新增挂载通过 seccomp 过滤mount系统调用。同时在/proc可读范围内屏蔽其他进程的信息hidepid2挂载选项让沙箱进程只能看到自己的 PID避免通过/proc窥探宿主机进程表和命令行参数。3.2 资源耗尽与死循环模型生成的代码里死循环比恶意代码更常见。有时候只是逻辑写错一个while True没写退出条件有时候是模型把某个长任务的循环上限设太大了。这类问题不会攻击你但会消耗完配额影响整体服务的稳定性。OpenSandbox 用绝对时间超时和 CPU 时间超时双轨控制绝对时间到点强制杀进程CPU 时间到点同样杀掉。前者防挂起后者防那些通过 sleep 故意拖时间的脚本。3.3 网络外联与数据外传最隐蔽的一类风险是数据外传。恶意代码可能不去破坏系统而只是把沙箱里能读到的任何内容包括环境变量、用户上传的临时文件、模型上下文里的部分数据编码后发给某个公网地址。网络白名单能挡住大多数直连但还挡不住一种变通利用已允许的 API 域名做隧道。比如白名单里有api.github.com恶意代码就可以把数据编码进请求参数里丢过去。要完全封死这种隧道很难一个实用的缓解策略是对代理流量做内容长度和频率的限制单次请求体大小超过阈值直接拒绝同时沙箱出口全部走统一代理代理审计日志里保留完整的请求 URL 和 body 摘要后续可以离线分析。对于防不住的部分至少要保证可追溯。3.4 元数据泄露与记忆污染这是很多团队会忽略的点。模型执行代码时会用到环境变量里的 API Key、临时凭证这些变量如果被代码打印出来或者写进文件就会通过标准输出暴露。OpenSandbox 在输出过滤阶段会做模式匹配把疑似密钥串sk-开头、-----BEGIN开头等替换成占位符。还有一个更隐蔽的问题沙箱里跑过的代码可能修改模型自身的行为。如果允许把执行结果尤其是报错信息回传给模型作为下一轮上下文那恶意或错误的输出就有机会污染模型的上下文。OpenSandbox 的做法是回传给模型的输出必须经过归一化清洗去掉绝对路径、宿主机主机名、IP、密钥模式等标识信息保证模型看到的是一个干净的结果。攻击类型典型手法主要防御手段文件逃逸路径穿越、符号链接、枚举 /proc只读根fs、挂载校验、hidepid资源耗尽fork 炸弹、内存膨胀、死循环cgroup 限额、双超时网络外联数据外传、DNS 隧道、反弹连接网络白名单、代理净化、审计元数据泄露打印密钥、回传污染输出输出过滤、密钥掩码、清洗4. 沙箱内执行全流程从请求到结果归一化的七个环节4.1 静态预检与启发式拦截沙箱启动之前OpenSandbox 会对代码做一次快速静态检查。这一步不是要做出安全结论而是把明显可疑的调用先拦截掉降低沙箱被逼到极限的概率。检查项包括os.system、subprocess拼接命令里出现的管道符和重定向、eval/exec的字符串参数、base64解码后再次执行、对~/.ssh/、/etc/shadow等敏感路径的字符串引用。启发式规则会误杀所以 OpenSandbox 的静检默认不直接拒绝而是给代码打上一个风险标签。高风险标签会触发人工审批流程中风险标签会在沙箱环境里追加更严格的监控比如强制文件访问审计。这种软硬结合的策略既照顾了模型代码的多样性又守住了底线。4.2 镜像构建与依赖缓存沙箱运行需要基础环境Python 解释器、Node 运行时、系统库。OpenSandbox 按语言维护多个基础镜像镜像里预装常见的依赖包。为了避免每次执行都重新pip install联网拉依赖所有依赖都打包进本地缓存沙箱启动后直接用缓存里的包不发起任何出网请求。这一步直接消除了模型代码要求安装新包这种最常见的联网需求。依赖版本的处理也很有讲究。锁定的版本清单要定期更新但更新必须经过回归测试——因为模型生成的代码质量波动很大依赖版本跳动太频繁会导致同段代码今天能跑明天不能跑。我们的做法是每周批量更新更新后跑一轮全量回归样例库通过才发布新镜像。4.3 容器启动与探针注入容器启动后OpenSandbox 会注入一个监控探针进程。探针不干预应用逻辑但负责采集三件事当前运行的进程树、文件访问的边界违规事件、网络连接尝试记录。探针数据会写入一个宿主机侧只读挂载的日志通道应用代码没有权限访问这个通道。探针本身也是攻击目标——恶意代码拿到权限后第一件事可能是杀掉探针。所以探针以独立 PID namespace 外层的守护进程形式运行沙箱内无法直接对其发送信号。从实测来看探针进程存活性是判断沙箱是否健康的核心指标每 5 秒一次心跳连续三次丢失就判定沙箱失陷整机回收。4.4 执行监控与超时干预执行中的监控不仅是看死没死。OpenSandbox 会周期性快照沙箱的 CPU、内存、进程数与配额阈值做比较接近阈值时先告警超限时再强制终止。由于沙箱内部可能产生大量短命进程监控要特别注意一次快照时间内的进程总量变化而不是只盯着常驻进程。超时的设计是普通代码请求默认 30 秒 CPU 时间上限长任务代码可以申请延长到 5 分钟。但延长不是免费的需要在请求里显式声明并附带一个预期用时参数。这个参数会被记录用于后续的额度评估——如果某个用户总是低估用时系统会自动调低它的默认配额。4.5 输出清洗与归一化执行完成后原始输出不能直接返回给调用方。清洗分三步走第一步按字节数截断默认单次输出上限 1 MB防止模型代码打印出巨量数据把服务拖垮第二步做字符过滤把所有控制字符转义避免通过终端转义序列实施界面欺骗第三步做敏感信息掩码将路径、密钥、主机名等替换为脱敏占位符。这里分享一个教训早期我们只做了字节数截断结果某个模型生成的代码把二进制文件直接print出来了输出通道被灌进几万行乱码调用方前端直接卡死。后来加了可打印字符比例校验乱码占比超过阈值的输出一律替换为提示文本才消停。ANSI_ESCAPE re.compile(r\x1B(?:[-Z\\-_]|\[[0-?]*[ -/]*[-~])) def sanitize_output(raw: bytes, max_bytes: int 1_048_576) - str: text raw.decode(utf-8, errorsreplace) text ANSI_ESCAPE.sub(, text) text text.replace(\x00, ) printable_ratio sum(ch.isprintable() for ch in text) / max(len(text), 1) if printable_ratio 0.6: return non-printable output omitted return text[:max_bytes]5. 实战调优与踩坑记录冷启动、并发、误杀、日志5.1 冷启动优化预启动池与镜像分层沙箱最大的性能瓶颈是冷启动。第一次实测时一个 Python 沙箱从请求进入到代码开始执行平均耗时 4.2 秒其中 3.6 秒花在镜像拉取和容器创建上。对用户来说这就是模型给出代码后要干等四个多秒才能看到结果完全不可接受。优化方案是预启动池服务空闲时提前创建一批沙箱容器保持在待执行状态请求进来直接复用。池子的水位根据近一小时请求速率动态调节高峰期扩到 50 个低峰会缩到 5 个。启用预启动池后冷启动时间从 4.2 秒降到 300 毫秒代价是常驻的内存开销增加了约 2 GB——这是值得的因为用户体验的改善是数量级的。5.2 并发峰值下的容器回收策略沙箱容器不能无限堆积。OpenSandbox 的回收策略是执行完立即销毁容器但保留镜像缓存。销毁动作本身也有成本所以并发峰值时会碰到一个尴尬情况回收来不及容器数量超出预期。我们后来做了回收队列限速超过阈值的容器先暂停回收靠 cgroup 的配额硬限制压住资源占用等低峰期再批量清理。还有一次惨痛教训某天凌晨突然后台收到大量告警发现宿主机磁盘被撑满了。排查发现是一个沙箱的/workspace里被写入了大量临时文件tmpfs 配额没有正确应用到那个容器实例而清理任务只删容器没检查是否还有残留挂载点。从那以后回收流程强制多一步卸载挂载点验证并加了磁盘残留量的巡检告警。5.3 超时阈值怎么设不同语言不同命同一段逻辑用 Python 写可能跑 20 秒用 Go 写不到 1 秒用 Node 写 3 秒。如果超时阈值一刀切要么 Python 长任务频繁被杀要么 Go 的恶意代码有了更多时间搞破坏。OpenSandbox 的做法是按语言设置不同的基础超时再叠加请求方声明的预期用时做动态调整。更细的一层同一种语言不同类别的任务差异也很大。模型生成的文本处理类任务和数据爬取类任务I/O 等待时间和 CPU 时间比值完全不同。可以给执行实例配置CPU 时间/墙钟时间的比值上限比如墙钟时间可以跑 60 秒但 CPU 时间最多 15 秒这样既允许等待网络响应的场景又封死了纯 CPU 密集的死循环。5.4 误杀与被挡的合法操作沙箱机制一定会误伤一些正常请求。遇到最多的是两类一是某些第三方库会在运行时往用户目录或者/etc写配置比如有些 CLI 工具首次使用时会创建配置文件二是模型代码尝试访问沙箱外的网络资源比如查询某个需要直连的数据库。第一类问题的解法是给可写目录做白名单拓展在只读文件系统上叠加一层 OverlayFS把运行时可写的范围精确控制到库文件预期的配置路径而不是全部放开。第二类问题则需要业务侧配合把需要联网的代码单独分到一个有网络沙箱池里池内网络策略改为代理白名单模式池外保持默认禁网。5.5 监控与日志采集的隐蔽坑沙箱的日志采集如果设计不当会反过来成为逃逸入口。一个典型错误把宿主机日志目录直接 bind mount 进容器恶意代码如果能写日志就能往宿主机目录里塞任意文件后续再利用 cron 或者其他机制执行。OpenSandbox 的日志通道是单向的容器内进程只能往一个 FIFO 写宿主机侧的日志采集进程负责读取容器内没有任何路径可以触达宿主机的写入口。还有一个细节容易被忽略沙箱内进程如果一直在输出日志日志采集进程来不及消费FIFO 缓冲区满了以后写日志的进程会被阻塞进而拖垮整个沙箱的执行进度。解决办法是给日志通道加上截断策略超过阈值的日志直接丢弃只保留前 N 条和最后 N 条中间部分用一条摘要文本替代。最后再分享一个我在实际使用里的体会做模型代码沙箱不要追求一步到位的绝对安全那在工程上不存在。把隔离做到进程隔离加资源配额加固、把结果做到可清洗可追踪已经能覆盖绝大多数真实场景。剩下的极少数高威胁场景交给人工审批和流量审计比在沙箱层无限叠加机制更靠谱。这套思路目前在我们线上稳定跑了半年多模型生成的代码从几行 Python 脚本到多文件项目都在沙箱里执行出过问题但没有任何一次真正影响到宿主机和核心数据。
