技术摘要：AI 代码沙箱：对比安全性研究（第一部分）

问题陈述

本文探讨了 AI 智能体执行不受信任代码时，在**引擎级隔离（engine-level isolation）**方面面临的关键挑战。虽然“沙箱化”是智能体 AI 安全文献中的标准防御家族，但目前缺乏深入的、引擎层面的测量研究来比较不同产品如何隔离访客代码与宿主内核。这一紧迫性源于“危险能力（dangerous capability）”研究表明，AI 智能体已经具备执行多步网络攻击的能力（例如，在当前的计算预算内完成了 32 个企业网络攻击步骤中的 22 个）。本研究聚焦于 T0.H2.N2 威胁模型：即单租户运营商在其自有基础设施上运行不受信任的代码，其中运营商信任基础设施，但不信任代码。研究目标是衡量五种特定的 AI 沙箱产品（arrakis, e2b, microsandbox, gvisor, daytona）如何防止宿主内核逃逸和信息泄露。

研究方法

本研究采用了一个六轴、跨类别的对比框架，用于测量由底层引擎（微型虚拟机 microVM、用户态内核 userspace kernel 或 OCI 容器 OCI container）决定的属性。该方法明确禁止进行综合评分或整体排名，而是提供基于每个维度的排序以及威胁模型资格矩阵。

六个维度：

1. 宿主攻击面 (1.1)： 通过 strace 系统调用计数、seccomp 过滤器上限以及原始可达性（14 个特定的内核 LPE/容器逃逸原语）来测量运行时/中介器（L2）在宿主内核（L1）上的足迹。
2. 信息泄露 (1.2)： 测量通过 /proc、/sys 和 /dev 读取的内容，包括哪些宿主识别数据（CPU、RAM、内核版本、磁盘序列号）暴露给了访客。
3. 深度防御可叠加性 (1.3)： 评估运营商是否可以在引擎默认设置之上，叠加额外的 Linux 硬化措施（如 seccomp、AppArmor、用户命名空间等）。
4. 公开 CVE 历史 (1.4)： 分析各引擎过去 24 个月的 CVE 情况，并按影响类型（逃逸 Escape、宿主泄露 HostLeak、宿主拒绝服务 HostDoS）进行分类。
5. 补丁节奏 (1.5)： 测量上游补丁发布与产品级可用性之间的延迟，区分协调披露模式与“先静默修复再发布”模式。
6. 上游模糊测试态势 (1.6)： 评估是否存在持续的公开模糊测试（fuzzing）、树内 harness 以及针对每个 CVE 的发现归因。

实验设置：

• 宿主： 单台 Hetzner 裸金属节点（Ubuntu 24.04, Kernel 6.8.0）。
• 产品： 五个产品，映射到三种引擎类别：
  • 微型虚拟机 (MicroVMs)： arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun)。
  • 用户态内核 (Userspace Kernel)： gvisor (runsc)。
  • OCI 容器 (OCI Container)： daytona (runc via Docker-CE)。
• 验证： 使用“探测（probe）”测试（通过/失败）、“测量（measurement）”（系统调用计数）以及“桌面研究（desk research）”（CVE/模糊测试分析）。

核心贡献与发现

1. 引擎类别与产品差异

虽然引擎类别（微型虚拟机 vs. 用户态内核 vs. 容器）在架构轴（攻击面、泄露）上划分清晰，但同类产品之间并不一致。产品的配置和锁定策略（pin policies）往往比引擎类别本身更具差异性。

• 示例： arrakis（微型虚拟机）拥有“冻结”的补丁策略（471+ 天），而 daytona（容器）在补丁方面保持“当前”状态，这反转了仅基于隔离类别的预期安全层级。

2. 攻击面与原语可达性

• g-visor 拥有最紧凑的攻击面（5/14 个原语可达），因为它使用用户态内核拦截系统调用。
• Firecracker (e2b) 拥有最严苛的 seccomp 上限（55 个系统调用），但仍在使用窗口期内出现了 2 个新的 Escape 类 CVE，这证明了较小的攻击面并不能保证在已执行路径中零漏洞。
• arrakis 向访客暴露了一个实时的 /dev/kvm 接口，允许在不进行权限提升的情况下进行嵌套虚拟化，与其它微型虚拟机相比，显著扩大了其内核 LPE 攻击面。

3. 补丁传播的主导地位

研究发现，**产品侧的锁定策略（pin policy）**是主导的面向运营商的变量，其聚合结果为：对于协调披露，延迟约为 0 天；而对于下游，延迟范围从 0 到 471+ 天不等。

• arrakis 和 e2b (自托管版) 处于较旧的引擎版本“冻结”状态，未能针对近期的关键 CVE 进行修复（例如 arrakis 的 CVE-2026-45782 和 e2b 的 CVE-2026-5747）。
• g-visor 遵循“先静默修复”模式，其修复程序在 CVE 分配前数月即可交付，导致了负向延迟（运营商在公开披露前即可获得修复）。

4. 模糊测试态势与“未测量”风险

• g-visor 是唯一拥有持续公开模糊测试器（syzkaller）和树内 harness 的引擎。
• Firecracker 和 libkrun 均没有上游模糊测试基础设施。
• 关键发现： “微型虚拟机类别”（强隔离）与“持续公开模糊测试器”（强残余漏洞检测）的结合在本次测试集中是空白的。
• libkrun (microsandbox) 在结构上是未被测量的：它有 0 个已发布的 CVE 且没有上游模糊测试器。论文认为，这里的“0 个 CVE”是信号的缺失，而非健全性的证明，从而创造了一种“结构性未测量”的风险特征。

5. 信息泄露

• 微型虚拟机 (MicroVMs) 通常泄露 0–1 个宿主标识符（可配置的 CPU 字符串）。
• g-visor 由于其合成 /proc 的实现缺陷，泄露 2 个标识符（RAM 总量、BIOS 产品）。
• daytona 泄露 10 个标识符，包括磁盘序列号和完整的内核签名，这是由于其共享内核架构导致的。

重要性与主张

本文声称无法也未提出任何整体排名。相反，它提供了一个威胁模型资格矩阵，允许运营商回答四个特定的子问题：

1. 逃逸抗性： 代码能否逃逸宿主内核？
2. 侦察抗性： 代码能了解多少关于宿主的信息？
3. 硬化兼容性： 运营商能否添加 Linux 硬化层？
4. 补丁传播： 运营商能否及时获得修复？

主要结论：

• 权衡是不可避免的： 最强的隔离类别（微型虚拟机）并不自动等同于最强的残余漏洞态势（模糊测试）。运营商必须在“最强隔离”（微型虚拟机）与“最浅残余漏洞”（g-visor）之间做出选择。
• 产品默认设置至关重要： 引擎层面的优势（例如 Cloud Hypervisor 的每线程 seccomp）可能会被产品层面的默认设置所抵消（例如 arrakis 的嵌套 KVM 暴露或 e2b 的冻结锁定）。
• “未测量”差距： libkrun 中 CVE 的缺失和模糊测试的缺失创造了一种无法被推断为“安全”或“不安全”的风险特征，只能被称为“未测量”。
• 方法论转变： 本研究超越了简单的 CVE “重放”，通过对架构属性、补丁节奏和模糊测试投入的元分析，来描述当前 AI 沙箱安全的现状。

本文作为引擎级测量的基准，识别了特定的产品级配置缺陷（如 arrakis 的嵌套 KVM 和 daytona 的 Privileged: true 硬编码），这些缺陷需要运营商立即关注或进行上游修复。