在日常开发中，我们经常需要运行来源不明的代码：安装一个 npm 包可能触发 postinstall 脚本，执行一个不熟悉的仓库的构建命令，或者让 AI 编程助手在本地执行任意代码。这些场景的共同点是：我们需要运行代码，但又不想承担完全信任它带来的风险。传统的解决方案是容器或虚拟机，但它们的启动开销和配置复杂度往往与「快速验证」的需求相悖。Fence 的设计目标正是在这两个极端之间找到平衡：它不提供容器级别的强隔离，而是通过操作系统原生的轻量级沙箱机制，为命令行工具添加一层可配置的「护栏」。
架构设计：双层隔离模型
Fence 的核心架构建立在两层隔离之上。第一层是操作系统级别的进程隔离，第二层是基于代理的网络域名过滤。这种分层设计使得它能够在不引入完整容器运行时的情况下，实现对网络和文件系统访问的精确控制。
在 Linux 平台上，Fence 依赖 bubblewrap（简称 bwrap）来实现进程隔离。bubblewrap 利用 Linux 内核的用户命名空间（user namespace）功能，将目标进程放入一个隔离的环境中。通过一系列参数配置，它可以限制进程可见的文件系统视图、隔离网络命名空间、禁用系统能力（capabilities），甚至阻止进程访问其他进程。例如，一个典型的 bubblewrap 调用会将 /usr、/bin 等系统目录以只读方式绑定挂载，同时创建一个全新的网络命名空间，使得沙箱内的进程无法直接访问外部网络。这种隔离方式的优点是开销极低 —— 它不需要启动完整的容器镜像，只需要几个系统调用就能完成设置。
macOS 平台缺乏 bubblewrap 这样的原生工具，Fence 转而使用苹果的 sandbox-exec 机制。sandbox-exec 是 macOS 系统提供的一个沙箱执行工具，它通过 Seatbelt 配置文件（一种声明式的策略语言）来定义进程可以执行的操作。Fence 根据用户配置动态生成这些策略文件，控制文件系统访问、网络连接、进程派生等行为。虽然 sandbox-exec 的能力不如 bubblewrap 灵活，但对于常见的隔离需求已经足够。
网络隔离是第二层防御。即使进程被 bubblewrap 放入独立的网络命名空间，它仍然可能通过某种方式访问外部 —— 比如利用本地回环地址连接到宿主机器上的代理。Fence 的做法是在沙箱内设置环境变量（如 HTTP_PROXY、HTTPS_PROXY），将所有出站 HTTP/HTTPS 请求定向到本地的一个小型代理进程。这个代理维护着一个域名白名单，未经授权的域名请求会被直接拒绝。这种设计的好处是配置简单、兼容性好，curl、git、npm、pip 等工具都会自动遵循代理环境变量。
安全模型：纵深防御与能力边界
理解 Fence 的安全边界对于正确使用它至关重要。它的设计定位是「半信任代码的纵深防御」，而不是「恶意代码的坚固牢笼」。这个定位决定了它的能力范围和局限性。
在威胁模型的正面，Fence 能够有效应对几类常见风险。首先是供应链脚本的意外外联：许多 npm 包和 Python 包的安装过程会执行 postinstall 脚本，这些脚本可能尝试向遥测服务发送数据，或者检查更新。在 Fence 的默认配置下，所有网络出口都被阻断，除非显式允许特定域名，这使得这类行为会被立即阻止。其次是文件系统的意外写入：Fence 默认拒绝所有写入操作，用户需要通过 allowWrite 配置显式指定允许写入的目录。这可以防止 npm install 把文件撒得到处都是，或者一个构建脚本意外覆盖重要的配置文件。第三是敏感信息的意外泄露：如果一个工具尝试将环境变量或本地文件内容发送到外部服务器，网络阻断和文件系统读取限制会共同阻止这类行为。
在威胁模型的背面，Fence 明确声明了几类它不试图解决的问题。它不是为抵御「蓄意恶意」的代码而设计的：如果攻击者知道自己在沙箱中运行，他们可能尝试利用内核漏洞逃脱命名空间隔离，或者滥用未受限的系统调用。Fence 也没有资源限制功能 —— 它不能阻止一个进程消耗 100% 的 CPU、耗尽内存、或用磁盘填满整个硬盘。此外，基于代理的域名过滤只能作用于尊重 HTTP_PROXY 环境的程序；直接使用原始套接字或自定义网络栈的工具可能会绕过这一层检查。
环境变量清理是 Fence 安全模型中一个常被忽视但很重要的细节。在 Linux 上，它会剥离所有 LD_* 开头的变量（如 LD_PRELOAD、LD_LIBRARY_PATH）；在 macOS 上，则处理 DYLD_* 开头的变量（如 DYLD_INSERT_LIBRARIES）。这防止了一种特定的攻击链：假设沙箱内的代码先写入一个恶意动态链接库到临时目录，然后在后续命令中通过 LD_PRELOAD 加载它来执行任意代码。如果没有这层清理，这个后利用技术可能会成功。
配置策略：从模板到精细控制
Fence 提供了多种配置方式来适应不同的使用场景。对于最简单的情况，直接运行 fence <command> 会以「阻断所有网络、阻断所有写入」的默认配置执行命令。如果需要更细粒度的控制，可以通过 -t 参数指定模板，或者通过 -c 参数直接内联配置。
模板机制是 Fence 的一大便利特性。它内置了几个常用模板（如 code 模板针对 npm/pypi 注册表进行了优化），也支持用户自定义模板。模板本质上是一个 JSON 配置文件，位于用户主目录下的 .fence.json，它定义了允许的域名、可写的目录、需要阻断的命令等策略。例如，一个用于前端开发的模板可能允许访问 registry.npmjs.org 和 cdnjs.cloudflare.com，同时将工作目录下的 ./node_modules 和 ./dist 标记为可写，而将 ~/.ssh 和 ~/.aws 标记为禁止读取。
命令阻断规则是另一层防护。Fence 允许在配置中列出需要直接拒绝的命令模式，常见的如 rm -rf /、git push、npm publish 等。这不是通过文件名匹配实现的，而是对完整命令行的文本匹配。当用户尝试执行匹配的命令时，Fence 会在实际运行前直接拒绝并返回错误。这对于 CI/CD 场景特别有用：即使攻击者获得了执行 shell 的机会，他们也无法执行那些高风险操作。
监控模式（fence -m <command>）是调试和发现问题的利器。当开启监控时，Fence 会在标准错误流中输出所有被阻断的访问尝试，包括尝试访问的域名、被拒绝的文件路径、触发的规则等。这使得用户可以在正式使用前「探测」一个工具的行为模式，然后相应地调整白名单配置。例如，运行 fence -m -- npm install 可能会显示它尝试访问哪些注册表域名、写入哪些临时目录、读取哪些配置文件，从而帮助用户写出精确的隔离策略。
工程权衡：轻量与坚固的取舍
选择 Fence 而非完整容器解决方案，本质上是在安全强度和运维复杂度之间做权衡。容器提供了更强的隔离 —— 网络命名空间、文件系统隔离、资源限制、完整的进程树控制 —— 但代价是需要准备镜像、管理网络地址转换、处理存储卷挂载。对于一个「临时运行一条命令」的场景，这些开销往往是不值得的。Fence 的轻量级方案恰好填补了这个空白：它几乎即时启动（不需要拉取镜像），配置是简单的文本文件（不需要编写 Dockerfile），而且与宿主系统的集成更自然（可以访问宿主的文件系统而不需要显式挂载）。
这种设计选择也意味着 Fence 不适合作为唯一的安全边界。如果你的威胁模型包括「攻击者可能执行任意代码并试图逃脱沙箱」，你应该考虑使用轻量级虚拟机（如 gVisor、Firecracker）或者完整的容器编排系统。Fence 的正确用法是作为多层防御中的一环：它降低的是「常规风险」（意外的网络泄露、错误的写入位置）发生的概率，而不是「高级威胁」（内核利用、权限提升）的成功概率。
从工程实现角度看，Fence 的代码库值得学习。它是一个相对纯粹的 Go 项目，代码结构清晰，核心逻辑集中在 pkg/fence 目录下。如果你正在设计类似的隔离工具，或者需要为现有的 CLI 工具添加沙箱能力，Fence 的实现细节 —— 如何拼接 bubblewrap 参数、如何生成 sandbox-exec 配置文件、如何协调代理进程的生命周期 —— 都是很好的参考。
落地建议
在实际采用 Fence 时，有几个实践建议值得关注。首先是渐进式启用：不要一开始就试图写出完美的隔离策略，而是先用监控模式运行常用命令，观察它们的真实行为，再逐步收紧规则。其次是模板复用：将团队常用的配置固化为模板，通过版本控制共享，这样既保证了一致性，又降低了每个人的配置负担。第三是明确预期：向团队传达 Fence 的能力边界 —— 它能防止意外，但不能阻止蓄意 —— 避免因误解其安全定位而导致的配置不当。
对于 AI 编程助手的使用者，Fence 提供了一种在享受助手便利性的同时降低风险的方式。通过为助手配置专门的模板（比如只允许访问相关的代码仓库和包管理服务，禁止写入敏感目录），即使助手「失控」，损害也能被限制在可控范围内。这种「权限管理」的思路，也是未来人机协作安全的重要方向。
资料来源：Fence GitHub 仓库（github.com/Use-Tusk/fence）、安全模型文档、Architecture 文档。