沙盒技术这个词这几年被提得很多但真正在工程里落地的时候绝大多数团队踩的坑都不是“不知道怎么隔离”而是“隔离得不对”。我印象很深的一次某团队为了跑一批第三方提交的自动化脚本图省事直接在业务机上开了个低权限账号就跑了结果一个死循环脚本把 CPU 吃满连带同机的服务全部超时排查了两个小时才定位到根因。从那之后我对沙盒技术的理解就变了它不是一道保险丝而是一整套关于“边界怎么划、代价付多少、失效了怎么办”的工程取舍。这篇内容想聊的就是这个沙盒技术到底是什么、它在内核层靠什么撑着、从零怎么搭一个够用的最小实现、不同场景下该选哪一档强度、以及真正上线后会在哪些地方翻车。适合三类人看——做后端或平台工程、需要跑不可信代码的同学做客户端、要处理外部文档和插件的同学还有单纯想把“隔离”这件事的原理搞明白的读者。不需要你已经是内核专家但至少要能看懂基本的 Linux 命令和进程概念。下面我尽量把每个“为什么这么设计”都讲透而不是甩一堆配置让你照抄。1. 沙盒技术的本质它到底在隔离什么1.1 把“不可信”关进一个可控的房间剥掉所有实现细节沙盒技术干的事只有一件让一段代码在运行时它对系统资源的所有访问都必须经过我设定的关卡。这里的“资源”包括 CPU 时间、内存、磁盘、网络、设备、以及其他进程。关卡的设计决定了沙盒的强度关卡漏了哪里沙盒就在哪里破。我习惯用租房来类比。你租出去一间房房里有床有水电但你不希望租客去动你主卧的抽屉、不希望他把整栋楼的总闸拉了、也不希望他半夜开派对吵到邻居。对应到技术层面对应四件事文件系统要能看到但改不了关键部分抽屉、资源要有上限总闸、影响范围要收敛邻居、身份要降级不能拿着房东的钥匙。这四件事分别对应挂载隔离、cgroup 限额、命名空间、权限降权缺一个都不算合格的沙盒。很多人第一次接触沙盒会觉得它很神秘其实你每天在用。浏览器打开一个网页那个页面的 JavaScript 跑在渲染进程里拿不到你的本地文件列表也读不了另一个标签页的内存这就是沙盒。手机上的应用装完弹出一堆权限申请本质也是沙盒边界在向你暴露“我需要越界”。理解了这四个维度后面所有的技术选型都只是在这四个维度上做加减法。1.2 四种主流沙盒形态的横向对照在实际工程里能碰到的沙盒大致可以归成四类。它们的强度、开销、易用性差异非常大选错了要么性能崩要么安全感是假的。形态隔离粒度启动开销隔离强度典型适用场景语言级沙盒同一进程内极低微秒级弱依赖解释器自身无缺陷模板渲染、表达式求值、配置脚本系统调用过滤进程级低一次装载常驻中可精细到单个调用长期驻留的解析服务命名空间 挂载隔离进程组级中毫秒到几十毫秒较强文件与网络边界清晰批量任务、代码评测、插件运行硬件虚拟化整机级高百毫秒到秒级最强内核也被隔离高价值不可信负载、多租户这张表最容易被误读的地方是“强度”这一列。强度不是越高越好因为强度直接换算成钱和延迟。我见过有团队为了跑几个简单表达式硬上微虚拟机结果单次请求 P99 从 8ms 涨到 400ms用户直接投诉。也见过反过来的把用户上传的脚本放在语言级沙盒里跑问题是那个解释器本身就带文件读写能力等于门锁装了但钥匙插在门上。选型的判断标准我一般问三个问题这段代码是谁写的、它出错时最坏能造成什么后果、我能接受多少额外延迟。三个答案基本就把方案框死了。第三方开发者提交的代码、后果可能是数据泄露、延迟敏感度低那就往命名空间或虚拟化走自己内部写的规则表达式、后果最多是算错、延迟敏感语言级沙盒完全够用。1.3 一个常见误解沙盒不等于虚拟机这两个概念在讨论里经常被混着用但它们解决的问题不一样。虚拟机关心的是“模拟一台完整的机器”沙盒关心的是“限制一个程序能碰到什么”。虚拟机天然包含沙盒能力因为里面有独立内核但代价是你要为每个实例付出一整套操作系统启动的成本。反过来沙盒做得好不好跟有没有虚拟机没关系。一个只用命名空间隔离的容器如果配置得当对绝大多数不可信代码的防护已经足够而一个配置不当的虚拟机比如把宿主机目录直接共享进去、又给了 root 权限照样能被穿透。我个人的经验是先想清楚威胁模型再决定要不要付虚拟化的钱。威胁来自“写错代码导致资源耗尽”命名空间加限额就够了威胁来自“有人刻意构造攻击载荷”才需要考虑内核层面的隔离。还有一个更隐蔽的误解很多人以为沙盒是“一次性”的跑完就销毁所以不用管内部状态。实际上如果你的沙盒复用上一个任务留下的临时文件、环境变量、缓存目录都可能成为下一个任务的攻击面。这个坑我在第 6 节会详细展开。2. 底层机制拆解权限、文件系统与系统调用2.1 最小特权先把钥匙交出去再谈隔离所有隔离手段里降权是最便宜也最容易被跳过的一步。逻辑很简单如果进程本身是 root那它绕过大部分用户态限制只是时间问题如果它是普通用户很多破坏性操作在内核第一道检查就被拦下了。我的固定做法是沙盒进程必须以专用低权限账号运行这个账号不做任何其他事家目录是空的或只读的不在 sudo 组里也没有任何能力位。在 Linux 上可以用setpriv或capsh把能力集清空只保留真正需要的那几个。绝大多数计算型任务一个能力位都不需要。# 以专用低权限用户启动清空所有能力位禁止新增特权 setpriv --reuid61000 --regid61000 --clear-groups \ --inh-caps-all --ambient-caps-all --bounding-set-all \ --no-new-privs \ /opt/sandbox/runner--no-new-privs这个参数值得单独说。它防止进程通过 setuid 程序重新获得特权是阻断“降权后又被提权”这条路径的关键开关。我见过有团队做了降权但漏了这个标志结果沙盒里的代码执行了一个带 setuid 位的二进制权限又回去了前面所有隔离白做。注意降权和隔离是两件事不能互相替代。只降权不隔离进程仍然能看到整台机器的文件只隔离不降权进程在隔离环境里还是老大。两个都得做。2.2 文件系统隔离的三层做法文件系统是最直观的攻击面。不可信代码最常干的事就是到处翻文件、往临时目录写东西、读取配置里的密钥。隔离手段从弱到强大致三层。第一层是chroot把进程的根目录换成一个子目录。它很老、很简单但不够安全因为如果你在 chroot 环境里保留了 root 权限是有办法跳出去的。所以 chroot 必须配合降权使用降权之后它才真正有意义。第二层是挂载命名空间配合只读绑定挂载。这是我现在最常用的方式给沙盒准备一个最小根目录把需要的系统库以只读方式绑进去工作目录单独挂一个可写的小分区其他全部不可见。好处是权限边界非常清晰坏处是要手工整理依赖。# 在挂载命名空间内构造最小根 mount --bind -o ro /usr/lib $ROOT/usr/lib mount --bind -o ro /usr/bin $ROOT/usr/bin mount --bind -o ro /etc/ld.so.cache $ROOT/etc/ld.so.cache mount -t tmpfs -o size64m,mode1777 tmpfs $ROOT/tmp mount -t tmpfs -o size16m,mode0700 tmpfs $ROOT/work这里有个细节/etc不要整个绑进去。配置文件里可能有凭据、可能有主机信息只绑真正需要的单个文件。我一般只放ld.so.cache、nsswitch.conf、resolv.conf这三个其他一律不给。第三层是pivot_root彻底切换根配合卸载旧根。它比 chroot 干净因为旧根被真正移除了进程连“跳回去”的路径都没有。容器运行时基本都用这个。手写的话稍微麻烦一点需要先把新根挂成挂载点再调用pivot_root然后umount旧根。如果你的场景要求比较高值得花这个功夫。2.3 系统调用过滤白名单比黑名单靠谱命名空间解决了“看得见什么”但没解决“能做什么”。进程仍然可以调用几千个系统调用其中不少带着风险比如创建新进程、加载内核模块、修改系统时间、建立原始套接字。这一层靠 seccomp 做过滤。它的工作方式是在进程上挂一个 BPF 程序每次系统调用进来先过一遍过滤器命中规则就返回错误或者直接杀掉进程。关键的设计选择是用白名单还是黑名单。我的建议是能白名单就白名单。黑名单的问题在于你永远想不到漏了哪个而且内核新增调用时你的列表就过期了。白名单虽然前期麻烦需要一个个试出程序真正用到哪些调用但边界是闭合的。实际操作中可以用strace -c跑一遍正常流程把调用列表收集出来再去掉明显危险的那些剩下的就是初始白名单。{ defaultAction: SCMP_ACT_ERRNO, architectures: [SCMP_ARCH_X86_64], syscalls: [ { names: [read, write, exit, exit_group, futex, mmap, mprotect, munmap, brk, rt_sigaction, rt_sigprocmask, clock_gettime, getpid, gettid], action: SCMP_ACT_ALLOW }, { names: [clone, clone3], action: SCMP_ACT_ALLOW, args: [{ index: 0, value: 65536, op: SCMP_CMP_MASKED_EQ }] } ] }上面这段是 OCI 风格的 seccomp 配置片段defaultAction设成SCMP_ACT_ERRNO意味着没列出来的一律返回错误。clone那条用掩码限制了只能创建线程CLONE_THREAD不能创建新进程。这个细节很实用很多计算型任务需要多线程但不需要 fork限制住之后能挡掉一大类 fork 炸弹。提示白名单调试期会很痛苦程序动不动就 EPERM。建议先在审计模式下跑SCMP_ACT_LOG把被拦的调用记录下来观察一段时间再收紧成拒绝模式。上线直接开拒绝模式十有八九会挂。2.4 命名空间与资源限额看不见和用不完命名空间负责“看不见”cgroup 负责“用不完”两者配合才算完整。命名空间现在有好几种常用的几个是pid让沙盒内的进程看不到外面的进程同时保证沙盒内第一个进程是 PID 1退出时整个沙盒跟着退net给它一张独立的网卡甚至完全没网mnt隔离挂载视图user做用户 ID 映射ipc隔断共享内存。组合起来用才有效单开一个基本没用。cgroup 是限额的核心。v2 统一层级之后配置清爽很多主要管四个维度内存、CPU、进程数、IO。# 内存硬上限 512MB echo 536870912 /sys/fs/cgroup/sandbox/memory.max # 不做 swap 兜底超了直接 OOM echo 0 /sys/fs/cgroup/sandbox/memory.swap.max # CPU 配额周期 100ms配额 50ms等于 0.5 核 echo 50000 100000 /sys/fs/cgroup/sandbox/cpu.max # 进程数上限防 fork 炸弹 echo 256 /sys/fs/cgroup/sandbox/pids.max这几个数字怎么定第 3.4 节会给具体的计算方法。这里只说一个最容易忽略的点memory.max触发的是 OOM kill不是“拒绝分配”。也就是说内存打满时内核会直接杀掉沙盒里的进程。对批量任务来说这是可接受的但如果你在跑的是有状态的长任务需要考虑把上限设得宽一些或者在应用层做优雅退出。我曾经因为把上限卡得太紧导致一个正常的大文件处理任务在中途被 OOM反复重试看起来像是“随机失败”查了很久。3. 从零搭一个最小可用沙盒3.1 环境准备与选型思路这一节我把整个搭建过程走一遍目标是能跑一段不可信脚本跑完自动销毁跑的过程中即使脚本乱来也影响不到宿主机。用到的都是内核原生能力不依赖任何特定商业产品你在自己的测试机上就能复现。前提条件很简单Linux 内核版本不要太老cgroup v2 和较新的命名空间支持需要 5.x 以上有 root 权限用于一次性配置util-linux和libseccomp装好。生产环境里这些通常都有本地用一台虚拟机或者一台闲置机器练手即可。选型上我不打算用现成的容器引擎原因是它把很多细节封装掉了你学不到东西。我用手工拼装的方式每一步都能看清在干什么。理解之后再去看任何封装好的工具都能一眼看出它替你做哪几件事。整个流程分五步圈地命名空间、换根挂载与 pivot、限额cgroup、限权能力位与 seccomp、验收。下面一步步来。3.2 第一步用命名空间圈地最省事的做法是用unshare把所有命名空间一次性开出来。这条命令会创建一个全新的进程它拥有独立的 PID、网络、挂载、IPC、UTS 和用户视图。unshare --user --map-root-user \ --mount --pid --net --ipc --uts --fork --mount-proc \ bash -c echo inside pid: $$; ls /proc | head -5--map-root-user的作用是把当前用户映射成命名空间内的 root。这一步很关键因为它让你在沙盒内部拥有足够的权限去做挂载等操作但这些“权限”只在命名空间内有效出了这个边界什么都不是。这是 user namespace 最漂亮的地方不需要宿主机 root也能搭出一套隔离环境。--mount-proc会重新挂载/proc让沙盒内的进程看到的是自己的进程列表而不是宿主机的。如果不加这个ps会看到外面一堆进程隔离就不彻底了。跑完之后你可以验证一下在沙盒里echo $$得到的 PID 应该是 1 或者很小的数ip addr应该只有一张lols /proc里看不到宿主机的进程。这三条都对了圈地就算成功。注意--net会断掉网络。如果你的任务需要联网得另外配置网络命名空间内的虚拟网卡和转发这部分比较绕我一般建议先用“完全断网 通过挂载目录交换数据”的方式安全性高很多实现也简单。3.3 第二步挂载只读根与临时可写层有了命名空间接下来要构造文件系统视图。思路是准备一个空目录当新根把宿主机的必要部分以只读方式绑进去把可写部分换成 tmpfs最后pivot_root。NEWROOT/run/sandbox/root mkdir -p $NEWROOT/{usr,lib,lib64,etc,tmp,work,proc,dev} # 只读绑定系统目录 for d in usr lib lib64; do mount --bind -o ro /$d $NEWROOT/$d 2/dev/null || true done # 只放必要的配置文件不要整个 /etc for f in ld.so.cache nsswitch.conf; do [ -f /etc/$f ] mount --bind -o ro /etc/$f $NEWROOT/etc/$f done # 可写层用 tmpfs进程退出自动回收 mount -t tmpfs -o size64m,mode1777 tmpfs $NEWROOT/tmp mount -t tmpfs -o size32m,mode0700 tmpfs $NEWROOT/work # 最小化的 /dev 与 /proc mount -t proc proc $NEWROOT/proc mount --bind -o ro /dev/null $NEWROOT/dev/null mount --bind -o ro /dev/zero $NEWROOT/dev/zero mount --bind -o ro /dev/urandom $NEWROOT/dev/urandom几个设计取舍值得说明。为什么可写层用 tmpfs 而不是普通目录因为 tmpfs 只占内存进程退出后内容自动消失天然满足“用完即焚”也不需要你写清理脚本。代价是内存占用所以 size 要给死别让它无限涨。为什么/etc只绑单个文件因为整个目录里包含主机名、密码文件、各种服务配置随便一个都可能泄露信息。只绑ld.so.cache和nsswitch.conf是因为动态链接和用户查找需要其他都不给。如果你的程序不需要解析用户名nsswitch.conf也可以省掉。最后执行pivot_root把旧根彻底摘掉cd $NEWROOT mkdir -p .oldroot pivot_root . .oldroot umount -l /.oldroot rmdir /.oldroot exec chroot . /bin/bash到这一步/已经是新的了旧的文件系统被卸载进程手里的文件描述符指向的也是新根的路径。这比单纯chroot干净得多。3.4 第三步资源限额的参数怎么算限额参数拍脑袋定是很容易出事的。我给一个可复用的计算思路分四项。内存先测单次任务的峰值常驻内存用/usr/bin/time -v就能拿到Maximum resident set size。假设是 180MB然后考虑任务可能处理更大的输入按 2.5 倍冗余算 450MB再加 64MB 的运行余量得到约 514MB向上取整到 512MB 或 640MB 这种整齐的数。如果任务有多种规格按最大规格算或者做多档配置。CPU先确定你要允许多少并发核数。如果一台 8 核机器打算同时跑 16 个沙盒平均每个分到 0.5 核那就是quota50000, period100000。这里要注意cpu.max限制的是配额不是绑核进程仍然会在多个核之间迁移只是累计运行时间受限。进程数这个数是最容易被忽视的。pids.max卡的是线程和进程总数。一个 Java 程序光启动就几十个线程一个 Python 多进程任务可能有上百个。我的经验值是先给 512跑起来看pids.current的实际峰值再往下压到峰值的两倍左右。压得太低会莫名其妙地创建线程失败。磁盘如果用 tmpfs 做可写层size 就是磁盘上限。计算方式是最大输出文件大小 × 2 临时文件余量。比如输出可能是 100MB 的 CSV中间还要落一个 80MB 的临时文件那就给 300MB 左右。维度测量方法定值公式常见误区内存/usr/bin/time -v取峰值峰值 × 2.5 64MB忽略页缓存导致的虚高CPU单次执行耗时估算目标并发数反推配额以为配额等于绑核进程数观察pids.current峰值峰值 × 2忽略线程也算进程磁盘统计最大输出与临时文件输出 × 2 余量tmpfs 吃的是内存提示所有限额都要留“可观测”的口子。cgroup 里可以读memory.peak、cpu.stat的nr_throttled这些指标能告诉你限额是不是卡得太紧。nr_throttled持续很高说明 CPU 被限得厉害任务会变慢但不报错这种“慢性病”最难查。3.5 第四步系统调用白名单白名单的构建前面说过用strace -c收集这里补充实操细节。先跑一遍完整任务拿到调用频次列表然后把明显危险的一类删掉包括mount系列、ptrace、bpf、init_module、kexec_load、reboot、swapon、setns、unshare。这些要么能改系统状态要么能跳出当前命名空间。剩下的一股脑放进允许列表然后开审计模式跑一段时间。我一般会跑至少几十次真实任务观察有没有被拦的调用没在白名单里。确认稳定后再切成拒绝模式。有个细节execve要不要放行如果沙盒里的任务是通过 shell 启动子进程的必须放。但如果你的任务是一个单一可执行文件跑到底可以不放这样能挡住“下载一个二进制再执行”这类行为。我倾向于不放让任务只能跑我们指定的那个程序。openat和open是另一类需要斟酌的。完全禁止会让程序没法读文件显然不行。缩小风险的方式不是禁调用而是靠挂载层的只读绑定来限制路径两者配合才有效果。这也说明一个原则每一层只管自己该管的事别指望单层解决所有问题。3.6 第五步怎么验证它真的关得住搭完不算完得验证。我有一套固定的“捣乱测试”每次改配置后都跑一遍。测试项命令期望结果越权读文件cat /etc/shadow权限拒绝或文件不存在写根分区touch /test只读文件系统错误爆破内存循环分配大数组被 OOM kill宿主内存稳定fork 炸弹递归 fork达到 pids.max 后失败系统不卡建网络连接curl外部地址无网络或连接超时看宿主进程ps aux只看到沙盒内进程提权执行 setuid 程序权限不提升跑完这七项如果全部符合预期这个沙盒基本可用。任何一项不符合都要回头检查对应的那一层。我特别强调“爆破内存”这一项一定要在隔离的测试机上跑因为没有限额的话它真的会把宿主机拖死。我踩过的一次坑是 fork 炸弹测试通过了但内存测试失败。原因是pids.max限制了进程数但单个进程仍然能无限申请内存最后靠 OOM killer 兜底。虽然最终没崩但杀进程的时候误伤了同一台机器上另一个正常服务。后来加上了memory.max和oom.group让 OOM 时只杀沙盒内的进程组问题才解决。4. 落地场景不同领域的沙盒怎么用4.1 浏览器与文档解析最贴近普通人的隔离普通人每天都在用沙盒只是不知道。浏览器把每个页面、每个扩展放在独立进程里用系统调用过滤和渲染进程沙盒限制它的能力。你打开一个恶意网页它能做的顶多是让标签页卡死很难碰到你的本地文件。这个场景里最有借鉴意义的设计是多进程 权限剥夺组合。渲染进程被设计成“默认不能做任何危险操作”需要文件访问时由浏览器主进程代为执行主进程自己也是低权限的。这种“危险操作全部集中到一个小小的受控层”的思路在服务端同样适用。我在做文档解析服务的时候抄过这个思路。解析器本身跑在沙盒里只负责把文档转成中间格式不碰网络、不碰数据库真正的写库和通知交给外面的协调进程。这样即使解析器被构造的畸形文档打穿损失也止步于一个中间结果。4.2 在线代码评测与插件生态代码评测是最典型的场景用户提交任意代码你要编译、运行、拿结果还得保证用户 A 的代码不能影响用户 B更不能拿到评测机的任何数据。这个场景的沙盒要求比较特殊因为它需要短时间内高并发地创建和销毁。虚拟化方案在这里通常不可行冷启动太慢成本压不住。我见过做得比较稳的方案是长驻一批预热的沙盒池每个沙盒做完一次任务就整体销毁重建中间不做清理。重建的成本靠预热池摊销掉。插件生态是另一类。宿主程序加载第三方插件插件和宿主在同一台机器上语言可能都不一样。这种情况下沙盒边界通常画在“能力”上而不是“进程”上插件只能通过宿主提供的接口访问资源接口之外的一切都碰不到。这种模式强度低于进程隔离但对生态来说够用因为插件是开发者主动发布的有基本的信誉约束。4.3 数据处理与模型加载这一块最近问的人很多。加载外部来源的模型文件或者数据脚本本质上等同于执行别人的代码因为很多格式在解析时会触发反序列化甚至直接包含可执行逻辑。我的做法比较保守反序列化一律在沙盒内完成且沙盒完全断网。模型加载完成后把权重以纯数据格式比如二进制数组导出到共享目录再由主进程读入。这样即使解析过程被利用攻击者也只能拿到一个空环境。数据脚本同理。很多团队会让分析师写脚本处理数据这些脚本里什么都可能有包括误写的死循环和误删的路径。给每个脚本一个独立的限额沙盒跑完即毁是最省心的方式。这里有个实践细节把输入数据以只读方式挂进去输出目录单独挂一个可写 tmpfs脚本结束后由外部进程决定要不要把结果搬走。这样能挡掉“脚本删了原始数据”这类事故。4.4 客户端与服务端的边界差异同样叫沙盒客户端和服务端的关注点完全不同混着设计会出问题。服务端的核心诉求是多租户隔离和成本。一个沙盒挂了不能影响别人同时单实例成本要足够低。所以倾向轻量方案命名空间 cgroup 是主流配合严格的销毁流程。客户端的核心诉求是防本地数据泄露和防提权因为攻击者就在用户机器上物理接触是有的。这时候光靠命名空间不够因为用户自己就是管理员可以随意改配置。客户端更依赖系统提供的机制比如操作系统的应用沙盒、签名校验、以及把自己拆成特权进程和非特权进程两部分。我见过一个反例某桌面应用为了保证插件兼容性把插件直接加载进主进程只做了个“接口白名单”。结果一个插件里误用了系统 API把主进程搞崩了用户数据也丢了。这个案例说明客户端沙盒的边界应该画在进程之间而不是函数之间。5. 性能开销与分级策略5.1 开销来源拆解沙盒不是免费的知道自己为哪些东西付了钱才能决定哪些钱可以不付。开销来源量级是否可优化命名空间创建毫秒级通常 10ms可靠预热池摊销挂载与 pivot_root毫秒级取决于挂载点数量可减少绑定项cgroup 创建与配置毫秒级可复用 cgroupseccomp 装载微秒级一次装载不可免但很低系统调用过滤运行时单次几百纳秒高频调用会累积可减少白名单条目冷启动可执行文件数十到数百毫秒可预加载独立网络栈相对较高可不需要时直接断网最容易被低估的是“冷启动”这一项。如果你的沙盒每次都要从磁盘加载一个几百 MB 的运行时启动时间会远超隔离本身的成本。解决的思路是预热起一个沙盒池跑完的不要立刻销毁清理后放回池子里。清理的关键是彻底——工作目录重建、环境变量重置、文件描述符全关不能有残留。最容易被高估的是 seccomp 的运行时开销。实际上正常程序的系统调用以每秒几万次计每次过滤多几百纳秒总量也就毫秒级基本感知不到。真正慢的是“过滤器设计得太复杂”比如几百条带参数的规则串起来那就可感知了。把高频放行的调用放在最前面能让匹配更快。5.2 三档分级方案按我实际用下来的经验把沙盒分三档最实用团队里谁该用哪档一目了然。轻档独立用户 只读工作目录 资源限额不开命名空间。适合内部人员写的数据处理脚本威胁主要是“手滑”。开销几乎为零接入成本也低。中档命名空间 只读挂载 cgroup 限额 seccomp 白名单 断网。适合第三方提交的代码、插件运行、模型加载。这是绝大多数场景的正确选择我 80% 的项目都用这一档。重档在中档基础上加硬件虚拟化或独立内核。适合多租户 SaaS 里跑客户代码、以及处理高价值数据的场景。开销大但边界最硬。分档的意义在于避免“一刀切”。我见过所有任务都上重档的团队机器成本翻了几倍实际收益为零因为攻击面根本没到那个级别。也见过所有任务都走轻档的一次内部脚本误删差点把线上数据带走。5.3 逃逸风险的通用分析框架“沙盒能不能被逃出去”这个问题没有绝对答案但有一套可复用的检查方法。我不讲具体手法只讲该检查哪些位置因为对防守方来说这就够了。第一看共享资源。沙盒和宿主之间所有共享的东西都是通道共享目录、共享内存、共享网络、挂载进来的设备节点。逐个问“这个共享是必须的吗、能不能只读、能不能换成本地副本”。共享目录是最常见的问题源我的原则是能用一次性拷贝就不用长期挂载。第二看内核暴露面。沙盒里能调用多少系统调用、能访问哪些设备、内核版本有没有已知问题。前两项靠 seccomp 和最小化/dev控制第三项靠及时更新。这一块的检查应该做成周期性任务而不是上线前看一眼。第三看销毁流程。这个最容易被忽略。沙盒销毁时不彻底残留的文件、进程、挂载点会成为下一次的突破口。我一般会检查三件事进程是不是真的全退了包括孤儿进程、挂载点是不是都卸载了、临时目录是不是重建而不是清空清空可能漏掉隐藏文件。第四看横向移动。即使单个沙盒被攻破能不能从一个沙盒跳到另一个这取决于它们是否共享网络、共享存储、共享凭证。我在设计时会刻意让沙盒之间完全不可见每个都用独立的网络命名空间和独立的临时存储从一个逃到另一个的成本和从外面攻进来一样高。6. 常见问题与排查实录6.1 问题速查表现象可能原因排查方向程序启动即报权限错误seccomp 白名单缺条目看 dmesg 里的 audit 记录创建线程失败pids.max太小读pids.current对比峰值任务随机被杀内存超限触发 OOM读memory.events的oom计数任务变慢但无报错CPU 配额被打满读cpu.stat的nr_throttled找不到命令最小根缺目录或库检查绑定挂载列表无法解析主机名缺nsswitch.conf或断网确认是否本来就要断网输出文件为空写在 tmpfs 里没搬出来检查结果回收逻辑沙盒残留进程销毁时未杀进程组检查 PID 1 退出处理6.2 几个典型排查过程有一次线上出现“任务成功率约 92%”的怪现象失败的都是同一批稍大的输入。日志里没有任何异常进程就是消失了。第一反应是代码有 bug但同样的输入在本地跑百分之百成功。排查顺序是这样走的先看 cgroup 的memory.eventsoom计数和失败次数对上了问题就定位到内存限额。再看memory.peak发现峰值刚好压在memory.max上。结论很清楚输入变大后峰值内存超过了我们按平均情况定的限额。解决办法不是简单调大限额而是先把任务改成流式处理把峰值降下来同时把限额按新的峰值重算。这里想说的是OOM 的表现是“进程无声消失”日志里通常什么都没有很容易误判成别的故障。养成先看 cgroup 指标的习惯能省很多时间。另一次是nr_throttled的问题。某个任务在测试环境跑 3 秒线上跑 11 秒代码完全一样。查下来是线上沙盒的 CPU 配额按并发数除过之后只有 0.3 核而测试环境没设限额。这种“慢但不报错”的问题最难查因为所有人第一反应都是“线上机器性能差”。我的经验是给这类场景加一个显式的告警如果单次任务的 CPU 时间远高于基线就报警。这比人眼看出“好像变慢了”靠谱得多。还有一次是 seccomp 白名单导致的诡异失败。程序启动正常跑到某个分支时突然挂掉且没有错误输出。用strace一跟才发现某个系统调用返回EPERM而这个错误程序没处理直接走到了一条未定义的路径上。这件事给我的教训是白名单一定要从真实负载里收集不能凭经验列。而且测试用例要覆盖所有分支不能只跑主流程。后来我把SCMP_ACT_LOG的日志接进了监控任何被拦的调用都会打点一旦有新的调用出现立刻能发现。6.3 避坑心得第一条不要在沙盒里做登录鉴权。听起来很基础但我真的见过把数据库凭据通过环境变量传进沙盒的理由是“反正它用完就销毁”。问题是环境变量对沙盒内所有进程可见包括可能被注入的子进程也可能出现在崩溃转储里。正确做法是把数据通过标准输入或者一次性挂载的文件传进去用完即焚。第二条销毁流程要当成正经功能来开发。很多团队把清理写成一行rm -rf结果遇到挂载点残留、进程占着文件、符号链接指向外面等问题。我现在的做法是写一个独立的销毁组件先杀进程组等它真的退出再卸载所有挂载点按挂载顺序的反向最后重建目录。每一步都有超时和重试日志留全。第三条沙盒内的时钟和随机源要当回事。有些沙盒为了最小化会不挂/dev/urandom导致沙盒里的程序拿不到熵加密操作直接阻塞。也见过不挂/proc但程序依赖它的跑起来各种奇怪。我的最小集合里这两个是必给的另外/dev/null和/dev/zero也是。第四条别用“跑通了”当验收标准。跑通只能证明正常路径没问题沙盒的价值恰恰在于异常路径。前面那七项捣乱测试要坚持每次配置变更后都跑而且要自动化。我一般会把它做成一个脚本跟配置变更绑在一起跑不过就不让上线。最后分享一个扩展思路。如果你们的任务量上来了单机沙盒池会开始遇到调度问题怎么决定一个新任务进哪个沙盒、怎么在池子紧张时排队、怎么处理“卡死但不退出”的任务。这一层的复杂度往往超过沙盒本身。我个人的做法是给每个沙盒加一个硬超时超时就整个销毁重建不做任何挽救因为不可信代码卡死的原因你通常查不清重来比修复便宜得多。这个策略简单粗暴但在实际运行里省下来的排查时间远大于重建的成本。
