技术摘要：Sandlock

问题陈述

AI 代理和代码助手日益在开发者工作站上执行不受信任的代码，包括由大型语言模型（LLM）生成的 Shell 命令、第三方脚本以及工具插件。这造成了显著的供应链风险，单次调用可能导致意外的文件删除、SSH 密钥窃取或网络数据外泄。

现有的隔离机制无法适配此类特定工作负载：

• 容器与微虚拟机（MicroVMs）： 虽然提供强隔离，但启动延迟高（数百毫秒），且需要镜像管理、root 权限或复杂的命名空间配置，这对于短生命周期、高频次的代理命令而言是不可接受的。
• 临时控制措施： 诸如 chroot、ulimit、firejail 或 bubblewrap 等工具提供的保障较弱，缺乏细粒度的系统调用控制，且无法实施主机级或 HTTP 级的网络策略。
• gVisor： 引入了用户态内核以改善隔离性，但由于系统调用开销，导致构建工具的兼容性和性能下降。

核心挑战在于缺乏一种无特权、低延迟、感知文件系统且可编程的工具，能够在无需重启完整容器的情况下，强制执行依赖于运行时行为的策略（例如，在设置阶段后撤销网络访问）。

方法论与设计

Sandlock 是一个用 Rust 编写的轻量级、无特权 Linux 进程沙箱。其核心设计创新在于分离执行模型，将静态的、与输入无关的策略与依赖于运行时的决策分离开来。

1. 分离执行架构

Sandlock 将策略执行组织为两个不同的层级：

• 静态内核强制执行规则： 在执行前已知裁决结果的策略（例如，可读路径前缀、可写工作空间、TCP 端口、IPC 范围以及无条件系统调用拒绝）被编译为内核原语。Sandlock 利用 Landlock 实现文件系统、TCP 端口和 IPC 约束，并利用 seccomp-bpf 进行无条件系统调用过滤。该层级无需监督器参与即可运行，确保开销最小。
• 运行时监督器： 依赖于系统调用时状态的决策（例如，解析后的网络目的地、execve 参数、HTTP 方法/路径或写时复制效果）被路由至狭窄的 seccomp 用户通知 监督器。该监督器运行在父进程中，拦截特定系统调用，根据动态策略对其进行验证，并使用 pidfd_getfd 执行“代表”操作以确保安全。

2. 关键技术机制

• TOCTOU 安全的运行时策略： 为了在不违反内核重读语义的情况下安全地检查 execve 参数（如 argv），Sandlock 在读取参数或继续系统调用之前，通过 ptrace 冻结兄弟线程和对等进程。这防止了对等进程在验证后修改内存的竞态条件。
• 无特权写时复制（COW）： Sandlock 实现了两个 COW 后端，以在不使用挂载命名空间或 root 权限的情况下捕获文件系统写入：
  • Seccomp COW： 拦截文件系统系统调用，将写入重定向至上层目录。
  • BranchFS： 一个专用的文件系统层，在文件系统层面捕获写入。
    两者均支持在沙箱退出后提交、中止或检查更改。
• 流水线组合： Sandlock 引入了一个流水线操作符，通过内核管道连接沙箱化的阶段。每个阶段可以拥有不同的隔离策略（例如，具有私有文件访问权限但无网络访问的“数据”阶段，以及具有网络访问权限但无私有数据的“执行器”阶段）。这强制执行了抗提示注入架构（例如双 LLM 模式）所需的能力分离。
• 网络策略： Sandlock 支持端点白名单，并可选择 HTTP 级规则（方法、主机、路径）。对于 TCP，它使用 Landlock 进行直接的内核强制执行。对于复杂规则（HTTP、非 TCP），它使用“代表”路径，由监督器验证目的地并执行连接。

主要贡献

论文声称以下贡献：

1. 无特权代理的策略模型： 一种设计，将静态内核强制执行策略与依赖于运行时的监督器决策分离开来，同时保持统一的配置界面。
2. TOCTOU 安全的运行时机制（policy_fn）： 一种机制，将系统调用事件（包括 execve 参数）暴露给主机代码，以便在不违反内核重读语义的情况下进行实时策略收紧。
3. 无特权 COW 与 Fork 原语：
   • 一个由 seccomp 驱动的 COW 工作空间，允许在不使用 root 权限的情况下提交、中止或试运行文件系统效果。
   • 一个 COW-fork 原语，在 Map-Reduce 工作负载下支持每秒约 1,900 次沙箱化 fork。
4. 初步评估： 实证数据证明了低开销和高吞吐量。

结果

实验在标准 Linux 工作站上进行（AMD Ryzen 5, 8GB RAM, Linux 6.18）。

• 启动开销： Sandlock 增加了约 5 毫秒 的启动延迟（墙钟时间约 6 毫秒），在相同环境下比 Docker 快约 44 倍。
• 吞吐量： Sandlock 以 裸机吞吐量 运行 Redis（在测量噪声范围内）。对于 SET 和 GET 操作，Sandlock 分别实现了约 75.2k 和 74.2k 次请求/秒，而裸机分别为约 75.5k 和 73.9k。Docker 仅达到裸机吞吐量的约 76%。
• 延迟： Sandlock 的 p99 延迟（0.51 毫秒）接近裸机（0.49 毫秒），而 Docker 的 p99 延迟约为其 3 倍（1.44 毫秒）。
• 有效性： 确定性检查确认，Sandlock 正确拒绝范围外的读写操作，阻止非白名单的网络连接，并在流水线中强制执行每阶段的能力分离。

意义与主张

论文将 Sandlock 定位为针对 AI 代理工作站 的定制解决方案，解决了无特权、低延迟和可编程隔离的特定需求。

• 适度范围： 作者明确指出，Sandlock 并非多租户对抗环境中微虚拟机的替代品；对于此类场景，强内核隔离（微虚拟机）仍然是必要的。Sandlock 专为“开发者机器”环境设计，其中 root 权限不可用且延迟至关重要。
• 执行基底： Sandlock 提供了现有理论框架（如双 LLM 或 CaMeL 模式）所需的内核强制执行基底，以将不受信任的内容与敏感能力分离开来。它并未证明分解本身的正确性，而是强制执行作者指定的边界。
• 互补性： Sandlock 被呈现为与其他代理安全工具（如外部通信网关）的互补方案，通过保障代理栈的本地执行端来发挥作用。

论文结论指出，通过在分离架构中利用现代 Linux 原语（Landlock、seccomp 通知、pidfd_getfd），可以在无需传统容器化高昂成本的情况下，为 AI 代理实现强隔离。