跨平台主机隔离：为什么开了沙箱不等于隔离可信

1. 沙箱到底在防什么，为什么大家总觉得开了就万事大吉

很多人第一次接触“沙箱”这个词，是在浏览器里。Chrome 每个标签页一个进程，崩了一个不影响其他，这叫进程隔离；再往后一点，做后端或者做安全的朋友会接触到代码沙箱、支付沙箱、容器沙箱。名字都叫沙箱，但此沙箱和彼沙箱，防护的目标完全不是一回事。

我见过太多团队在评审会上拍胸脯说“我们代码已经在沙箱里跑了，隔离没问题”，结果一问细节：沙箱跑在宿主机的一个普通用户下，共享着同一个内核，网络走的是宿主机的网卡，文件系统挂的是宿主机的目录，只是加了个chroot或者seccomp规则。这种配置在 Linux 单机上确实能挡住一部分越权操作，但一旦你的业务要跨 Linux、Windows、macOS 三端跑，或者你的沙箱要处理来自不可信来源的代码，这套东西的边界就非常脆弱了。

先把概念掰开。沙箱本质上是一种“限制程序行为范围”的机制，它回答的问题是：这段代码能碰什么、不能碰什么。而跨平台主机隔离回答的是一个更底层的问题：这段代码运行的环境，和真实主机之间，到底有没有一条不可逾越的边界。前者是策略层面的约束，后者是架构层面的切割。两者经常被混为一谈，是因为在单机单用户的简单场景下，它们的效果看起来差不多——反正代码跑完就删，能出什么事？

问题就出在“跨平台”这三个字上。Linux 有 namespace 和 cgroup，Windows 有 Job Object 和 AppContainer，macOS 有 sandbox_init 和 Seatbelt 策略。这三套机制的抽象层次、能力边界、默认行为都不一样。你在 Linux 上用 seccomp 拦掉的系统调用，在 Windows 上根本没有对应的概念；你在 macOS 上依赖的 entitlement 签名，在 Linux 上完全不存在。所以当你把一套“沙箱方案”平移到另一个平台时，你以为自己开了沙箱，实际上可能只是换了个用户跑程序而已。

这篇文章想聊的就是这件事：为什么“已经开了沙箱”这句话，在跨平台场景下几乎等于没说。我会从隔离层级的拆解讲起，把 Linux、Windows、macOS 三端各自的隔离机制摊开对比，然后给出一个可落地的跨平台隔离检查清单，最后分享几个我在实际项目里踩过的坑。不管你是做代码沙箱、支付沙箱，还是做多端桌面应用的运行时隔离，这套思路都能直接拿去对照。

2. 把“隔离”拆成四层，才知道自己缺了哪一层

2.1 进程级隔离：最容易被误认为“够了”的那一层

进程级隔离是最基础的形态。Linux 上 fork 一个子进程，Windows 上 CreateProcess，macOS 上 posix_spawn，本质上都是让代码在一个独立的执行单元里跑。很多沙箱方案到这一步就停了，理由是“进程之间内存不共享，崩了也不影响主进程”。

这个理由在功能层面成立，在安全层面不成立。同一用户下的进程，默认可以互相 ptrace、可以读/proc/<pid>/mem、可以发信号、可以通过共享内存通信。Linux 上只要ptrace_scope没收紧，一个沙箱进程完全可以 attach 到主进程上读内存。Windows 上同一 session 内的进程可以通过OpenProcess拿到句柄，除非你显式设置了 DACL。macOS 上虽然 SIP 保护了一部分系统进程，但用户态进程之间的互操作依然宽松。

所以进程级隔离只能算“故障隔离”，不能算“安全隔离”。它的价值在于稳定性，不在于防御。如果你的沙箱要跑的是不可信代码，这一层远远不够。

2.2 文件系统隔离：chroot 不是银弹

文件系统隔离的常见做法是 chroot、bind mount、overlayfs。Linux 上chroot加pivot_root能做出一个看起来独立的根目录，但 chroot 有一个经典逃逸手法：如果进程有 CAP_SYS_CHROOT 能力，或者能拿到一个 chroot 外的文件描述符，就能跳出去。容器时代大家改用 mount namespace，效果好了很多，但前提是你真的用了 namespace，而不是只调了个 chroot。

Windows 上没有 chroot 的等价物，最接近的是文件系统虚拟化（如 Detours 重定向）或者 AppContainer 的文件访问限制。前者是 API hook，绕过方式很多；后者依赖 capability 声明，配置复杂且容易漏。macOS 的 sandbox 策略可以限制文件读写路径，但策略文件写错一个通配符，整个隔离就形同虚设。

跨平台做文件隔离，最稳的思路不是“在每个平台找等价物”，而是把工作目录做成一次性的、挂载进来的、生命周期和沙箱进程绑定的临时卷。沙箱启动时创建，退出时销毁，宿主机的真实路径永远不暴露给沙箱进程。这样无论底层是 namespace、Job Object 还是 Seatbelt，隔离效果都由“卷的边界”保证，而不是由平台机制保证。

2.3 网络隔离：最常被忽略的一层

我见过不少沙箱方案，文件隔离做得挺细，网络直接放行。理由是“沙箱里的代码需要下载依赖”。这个理由在开发场景成立，在生产场景是灾难。一个能自由发起网络连接的沙箱，等于给攻击者开了一条数据外传通道，也等于给内网扫描开了一扇门。

Linux 上网络隔离靠 network namespace，配合 veth pair 和 iptables 规则，可以把沙箱的网络限制到只有一个 loopback，或者只允许访问特定的代理地址。Windows 上可以用 Windows Filtering Platform 做进程级网络策略，但配置起来比 Linux 麻烦得多，而且很多开发者不熟悉。macOS 的 sandbox 策略可以限制网络访问，但默认策略往往允许 outgoing 连接。

跨平台网络隔离的实用做法是：在沙箱进程启动前，就把网络能力收掉。Linux 用unshare -n，Windows 用 AppContainer 的 network capability 不授予，macOS 用 sandbox 策略里的deny network*。如果业务确实需要网络，走一个受控的代理，代理层做域名白名单和流量审计。这样即使沙箱被突破，攻击者也拿不到原始网络栈。

2.4 内核级隔离：真正的边界在这里

前面三层都是“策略”，内核级隔离才是“边界”。Linux 的 namespace 把进程看到的 PID、网络、挂载、IPC、UTS、用户都做了视图隔离，cgroup 限制了资源用量，seccomp 限制了系统调用集合。这三者组合起来，才构成一个相对完整的隔离单元。缺了 namespace，chroot 可以被逃逸；缺了 seccomp，内核漏洞的利用面就大；缺了 cgroup，一个 fork 炸弹就能拖垮宿主机。

Windows 的对应物是 Job Object（资源限制）+ AppContainer（能力限制）+ 虚拟化安全（VBS/HVCI，硬件级隔离）。但 Windows 的 AppContainer 对传统 Win32 程序支持有限，很多老程序跑不起来，所以实际项目里经常退化成“低完整性级别进程”，隔离强度大打折扣。

macOS 的 Seatbelt 是策略引擎，不是资源隔离机制。它能限制文件、网络、IPC，但不限制 CPU 和内存。真正的资源隔离要靠 launchd 的 resource limit 或者外部的 cgroup 等价物，而 macOS 在这方面一直比较弱。

所以当你听到“我们开了沙箱”，第一反应应该是追问：哪一层？如果对方答不上来，那大概率只是进程级隔离，跨平台场景下基本等于没做。

3. 三端隔离机制横向对比：别指望一套配置走天下

3.1 Linux：能力最强，但配置最碎

Linux 的隔离能力是三者里最完整的，但也是最需要手工拼装的。一个典型的强隔离沙箱配置大概长这样：

# 创建隔离的命名空间 unshare --pid --net --mount --ipc --uts --user --map-root-user \ --fork \ # 限制资源 bash -c "ulimit -v 1048576; ulimit -u 64; exec /path/to/sandboxed_program"

再配合 seccomp 过滤系统调用，cgroup 限制 CPU 和内存，AppArmor 或 SELinux 做路径级访问控制。这套东西配好了，隔离强度很高。但问题在于：每一层都要单独配，漏一层就有一个缺口。我见过只配了 namespace 没配 seccomp 的，也见过配了 seccomp 但规则写得太宽（比如允许ptrace）的。

还有一个容易被忽略的点：Linux 的 user namespace 在部分发行版上默认关闭，或者需要sysctl kernel.unprivileged_userns_clone=1。如果你的沙箱依赖 user namespace 做 root 映射，部署到新机器上可能直接起不来。这个坑我在国产 Linux 发行版上踩过不止一次，不同发行版的内核配置差异很大，不能假设“Linux 都一样”。

3.2 Windows：抽象层次高，但可控性差

Windows 的隔离机制走的是另一条路。它不给你 namespace 这种底层原语，而是给你 AppContainer、Job Object、Integrity Level 这些更高层的抽象。好处是配置相对简单，坏处是你能控制的东西少。

AppContainer 是 Windows 上最接近“沙箱”的机制。它给进程一个独立的 SID，默认没有文件系统和注册表访问权，网络能力也要显式声明。但 AppContainer 对 Win32 程序的支持一直是个痛点，很多依赖 COM 或者特定 DLL 的程序跑不起来。实际项目里，大家经常退而求其次用“低完整性级别进程”，这个隔离强度就弱很多了，低完整性进程仍然能读大部分用户文件。

Job Object 主要用来做资源限制，比如限制进程数、内存、CPU 时间。它不提供文件或网络隔离。所以 Windows 上的完整隔离方案通常是 AppContainer + Job Object + 网络策略的组合，配置复杂度不比 Linux 低，只是碎的地方不一样。

还有一个现实问题：Windows 的很多安全机制依赖代码签名和 WDAC 策略，在开发机上配好了，到客户环境可能因为组策略限制跑不起来。这个在跨平台产品交付时特别容易翻车。

3.3 macOS：策略严格，但资源隔离薄弱

macOS 的 Seatbelt 策略引擎其实设计得很优雅。你用一段类似 Scheme 的 DSL 描述“允许什么、拒绝什么”，系统在内核层执行。比如：

(version 1) (deny default) (allow file-read* (subpath "/usr/lib")) (allow process-exec (subpath "/path/to/sandbox")) (deny network*)

这段策略的意思是：默认拒绝一切，只允许读/usr/lib，只允许执行指定路径的程序，禁止一切网络。看起来很美，但实际用起来有几个坑。

第一，策略文件写错不会报错，只会静默拒绝或者静默允许。调试起来很痛苦，得靠log stream看内核日志。第二，Seatbelt 不限制资源，一个沙箱进程可以吃满 CPU 和内存。第三，macOS 的 SIP 和 TCC 会在策略之上再加一层限制，有时候你的策略允许了，TCC 还是拦着，报错信息还不明确。

跨平台项目里，macOS 这一端经常是最后才适配的，因为开发者主力机是 Linux 或 Windows，macOS 的测试环境不好搭。结果就是 macOS 端的隔离配置最粗糙，往往只做了个sandbox_init调用，策略文件用的是最宽松的模板。

3.4 三端对比速查表

这张表想说明一件事：三端的隔离原语没有一一对应关系。你在 Linux 上用 seccomp 拦掉openat，在 Windows 上找不到等价物；你在 macOS 上用 Seatbelt 限制文件路径，在 Linux 上得用 AppArmor 或者手动 mount。所以“跨平台主机隔离”不是“在每个平台开个沙箱”那么简单，而是要针对每个平台的能力边界，设计不同的隔离策略，同时保证对外行为一致。

4. 一套可落地的跨平台隔离检查清单

4.1 启动前的静态检查

在沙箱进程启动之前，有几件事必须确认。这些检查不依赖运行时，纯配置层面就能做，适合放进 CI 流程。

第一，确认隔离机制真的生效了。Linux 上检查/proc/<pid>/ns/下的 namespace inode 是否和宿主机不同；Windows 上检查进程 token 里有没有 AppContainer SID；macOS 上检查sandbox_check的返回值。这一步很多团队跳过，结果沙箱配置写错了也没人发现。

第二，确认工作目录是临时卷。沙箱的工作目录不应该指向宿主机的任何持久化路径。Linux 上用 tmpfs，Windows 上用内存映射文件或者临时目录加 ACL，macOS 上用NSTemporaryDirectory加沙箱策略限制。目录的生命周期必须和沙箱进程绑定。

第三，确认网络策略是默认拒绝。不管业务需不需要网络，默认策略都应该是 deny，需要时再开白名单。这个原则在安全领域叫“默认安全”，但实际项目里经常反过来做——默认允许，出事了再加规则。

第四，确认资源上限已设置。CPU、内存、进程数、文件描述符数，这四项必须有上限。没有上限的沙箱，一个死循环就能拖垮宿主机。Linux 用 cgroup，Windows 用 Job Object，macOS 用setrlimit加 launchd 配置。

4.2 运行时的动态监控

静态检查只能保证配置正确，运行时还得盯着。我一般会在沙箱进程外面套一个监控层，定期采样几个指标：

• 系统调用频率：突然飙升可能是 fork 炸弹或者扫描行为
• 网络连接数：非白名单地址的连接尝试要告警
• 文件写入量：异常大的写入可能是数据外传
• 内存增长曲线：持续增长不回落可能是内存泄漏或者挖矿

这些指标不需要很精确，趋势比绝对值重要。Linux 上可以用 eBPF 做无侵入采样，Windows 上用 ETW，macOS 上用 EndpointSecurity 框架。如果不想搞这么重，至少用ps或者tasklist定期抓一下资源占用，超过阈值就 kill。

4.3 退出后的清理验证

沙箱退出后的清理经常被忽略。临时目录删了吗？网络规则回收了吗？cgroup 销毁了吗？AppContainer 的 profile 注销了吗？这些如果没做干净，下一次沙箱启动可能复用残留状态，导致隔离失效。

我的做法是写一个清理检查脚本，沙箱退出后跑一遍，确认所有临时资源都已释放。这个脚本在 CI 里跑，防止配置改动引入资源泄漏。Linux 上检查/sys/fs/cgroup/下对应的目录是否还在，Windows 上检查 Job Object 句柄是否关闭，macOS 上检查临时目录是否为空。

5. 实操中踩过的坑与排查思路

5.1 Linux 上 namespace 创建成功但隔离没生效

有一次在某个国产 Linux 发行版上，unshare --pid --fork返回成功，但沙箱进程里ps aux还是能看到宿主机的所有进程。排查了半天，发现是/proc没有重新挂载。PID namespace 只隔离了进程 ID 空间，/proc还是宿主机的，所以看到的是宿主机的进程列表。

解决办法是在 unshare 之后、执行目标程序之前，重新挂载/proc：

unshare --pid --mount --fork bash -c " mount -t proc proc /proc exec /path/to/program "

这个坑的教训是：namespace 隔离的是内核视图，不是文件系统内容。/proc、/sys、/dev这些虚拟文件系统如果不重新挂载，会泄漏宿主机信息。

5.2 Windows 上 AppContainer 程序启动失败

AppContainer 对 DLL 加载路径有严格限制。如果沙箱程序依赖的某个 DLL 不在 AppContainer 允许的路径下，程序会直接启动失败，错误码还很不直观。排查方法是看 Event Viewer 里的 AppContainer 相关日志，或者用Process Monitor过滤ACCESS DENIED。

解决办法有两个：要么把依赖 DLL 复制到 AppContainer 允许的目录，要么在 AppContainer 的 capability 里声明文件访问权限。前者简单但增加部署复杂度，后者灵活但配置容易漏。我一般先用前者快速验证，跑通后再优化成后者。

5.3 macOS 上 Seatbelt 策略静默失效

macOS 的 sandbox 策略如果语法有误，系统不会报错，而是按默认策略执行。默认策略往往是允许的，所以你以为隔离开了，实际上没有。验证方法是故意在沙箱里做一个应该被拒绝的操作，比如读/etc/passwd，看是否真的被拦。

还有一个坑是策略的继承。如果沙箱进程 fork 了子进程，子进程默认继承父进程的 sandbox 策略。但如果子进程 exec 了一个带 setuid 位的程序，策略可能会被重置。这个行为在文档里写得很隐晦，实际遇到时排查了很久。

5.4 跨平台常见问题速查表

6. 从“开了沙箱”到“隔离可信”还差什么

回到标题那个问题。为什么说“已经开了沙箱”不等于跨平台主机隔离做好了？因为沙箱是一个动作，隔离是一个结果。你调了sandbox_init、创建了 namespace、设置了 AppContainer，这些都是动作。动作是否达成了隔离结果，取决于配置是否正确、边界是否完整、跨平台是否一致。

我个人的经验是，判断一个跨平台隔离方案是否可信，看三个指标就够了。第一，默认拒绝：沙箱启动时，除了明确允许的能力，其他全部拒绝。第二，边界可验证：每个隔离维度都有对应的验证方法，不依赖“应该没问题”这种假设。第三，跨端一致：三端的隔离强度不能差太多，不能 Linux 端做了 seccomp 而 Windows 端只跑了个低完整性进程。

最后分享一个实用技巧。如果你不确定自己的沙箱隔离到底做到了什么程度，写一个“逃逸测试用例集”，包含文件读取、网络连接、进程枚举、系统调用、资源耗尽这几类操作，在三端各跑一遍，记录哪些被拦、哪些放行。这个测试集不需要很复杂，但能给你一个客观的隔离强度基线。每次隔离配置改动后重跑一遍，防止回归。

这个测试集我在多个项目里用过，最有用的一次是发现 macOS 端的网络策略写错了通配符，导致沙箱可以访问任意地址。如果只靠人工检查，这个错误可能到上线都发现不了。