openinterpreter（Codex）中 bubblewrap 安全策略解析：setuid 弃用、沙箱边界与责任归属模型

本文以 vendored 依赖 bubblewrap 的安全披露与边界声明文档为核心，解读它的两条安全立场——setuid root 模式下的最小攻击面承诺，以及“沙箱强度完全由调用方传参决定”的责任归属模型——并结合本仓库中 Codex Linux 沙箱对 bwrap 的实际封装（Rust FFI 垫片、命令行参数构造、内置二进制的摘要校验），说明这套策略在 0.11.2 版本下如何落地、以及评估 bwrap 相关 CVE 时应遵循的判断准则。

一、安全披露与响应政策

codex-rs/vendor/bubblewrap/SECURITY.md 开篇即声明：bubblewrap 项目遵循 Containers Projects 统一的《Security and Disclosure Information Policy》（由 containers/common 项目维护）进行漏洞披露。这意味着针对该依赖的安全问题不走独立渠道，而是纳入容器生态统一的披露与通告流程。

这一声明对阅读本仓库有实际意义：当你看到某个 bwrap CVE 时，其定级（是否为漏洞、严重级别、影响模式）以容器生态的统一判定为准，下文两节正是该判定框架的核心内容。

二、系统安全边界：setuid 与非 setuid 两种姿态

原文档“System security”一节给出了一个精确的威胁模型，值得逐条展开：

1. setuid root 模式下：目标是“不比 user namespace 更弱”。 若 bubblewrap 被设置为 setuid root，则其安全目标是：不允许一个恶意本地用户做成任何一件“在允许非特权用户创建 user namespace 的内核上本就能做到的事”。换言之，setuid 模式把自身定位为无特权 user namespace 的“子集实现”，而不是一个更强的隔离机制。文档举出的实例是 CVE-2020-5291：它被正式认定为 bubblewrap 的安全漏洞，正因为它突破了上述等价性承诺。

2. 非 setuid 模式下：bwrap 本身不构成用户与 OS 之间的安全边界。 如果 bubblewrap 不是 setuid root，那么它就不是用户与操作系统之间的安全边界——bubblewrap 能做的任何事，一个恶意用户完全可以用自己编写的等价工具做到。这不是缺陷，而是定位：此模式下 bwrap 只是沙箱构造工具，隔离强度取决于内核 user namespace 与调用方传参。

3. 自 0.11.2 起，setuid root 支持默认关闭。 原文档明确指出：自 0.11.2 版本起，除非编译时显式传入 -Dsupport_setuid=true，setuid root 支持是禁用的；这样构建出的二进制一旦发现自身被设置为 setuid 会拒绝运行。对于这种构建形态，可以安全地忽略所有“仅影响 setuid 模式”的 bwrap CVE。文档同时声明：这是推荐的打包方式。

仓库源码中的实现佐证

vendored 副本的构建脚本与这份声明完全对应，可以逐条验证：

• 版本与默认值：codex-rs/vendor/bubblewrap/meson.build 声明项目版本恰为 0.11.2；codex-rs/vendor/bubblewrap/meson_options.txt 中 support_setuid 选项的描述为 “Support setuid mode (deprecated)”，默认值 value : false，即默认不启用。
• 编译期行为：codex-rs/vendor/bubblewrap/meson.build 中仅当选项开启时才写入 ENABLE_SUPPORT_SETUID=1 配置宏，并打印告警 “running bubblewrap setuid is deprecated and risky…… Support for this will be removed in the next version.”。
• 代码层面：codex-rs/vendor/bubblewrap/bubblewrap.c 中，is_privileged 全局量仅在定义了 ENABLE_SUPPORT_SETUID 时才是真正的变量，否则直接 #define is_privileged 0——默认构建在编译期就抹掉了特权分支。
• 版本记录：codex-rs/vendor/bubblewrap/NEWS.md 的 0.11.2 发布说明记录了该选项的引入（“Binaries built with this will refuse to run if made setuid. We recommend building normal bubblewrap binaries like this”），并同列了 setuid 模式下的漏洞修复条目（CVE-2026-41163，低权限阶段 setup 进程不再以 dumpable 方式运行以避免被 ptrace）。
• 配套的运行时机制：codex-rs/vendor/bubblewrap/README.md 的 “System security” 一节补充了关键细节——bubblewrap 通过 PR_SET_NO_NEW_PRIVS 关闭 setuid 提权能力，这正是传统上防止进程逃逸出 chroot 环境的手段；README 同时重申 setuid 模式已弃用、默认构建的二进制在 setuid 状态下会拒绝工作。

从源码结构看，这套“编译期开关 + 运行时拒绝”的双保险使得本文文档中“这是推荐的打包方式”不是口号，而是有明确实现路径的策略。

三、沙箱安全责任模型：bwrap 是工具箱，不是成品沙箱

原文档“Sandbox security”一节是全文最容易被误读、也最容易被忽视的部分，其要点必须完整继承：

1. bubblewrap 是构建沙箱环境的工具箱（toolkit），不是一个带有既定安全策略的完整成品沙箱。
2. bubblewrap 的用途分为两类：一类需要沙箱与真实系统之间存在安全边界；另一类只是想改变沙箱内进程看到的文件系统布局，并不追求安全边界。
3. 因此，沙箱内进程与宿主系统之间的保护级别，完全由传给 bubblewrap 的命令行参数决定。
4. 构造这些参数的程序（通常是 Flatpak、libgnome-desktop、sandwine 这类更大的框架，或一段临时脚本）有责任定义自己的安全模型，并选择合适的 bwrap 参数来实现它。
5. 责任归属的经典判例：CVE-2017-5226 中，Flatpak 应用可以通过 TIOCSTI ioctl 向父终端注入输入——这被判定为 Flatpak 的漏洞，而不是 bubblewrap 的漏洞，因为终端暴露与否是上层框架传参策略的结果。

这一模型的工程含义是：审计 bwrap 相关系统时，必须区分“bwrap 本体缺陷”与“调用方参数缺陷”。后者归调用方负责，前者才进入 bwrap 的披露流程。

四、本仓库中的落地：Codex 如何扮演“负责传参的框架”

上述责任模型在本仓库中有直接的工程对应：Codex 的 Linux 沙箱把 vendored 的 bwrap 作为无特权沙箱执行器，而 codex-rs/linux-sandbox 这一层，正是原文档所说“负责定义安全模型并构造 bwrap 命令行参数”的那个上层框架。

• Rust FFI 垫片：codex-rs/bwrap/src/main.rs 通过 extern "C" 链接 vendored 源码导出的 bwrap_main，把 std::env::args_os() 转成 null 终止的 C 风格 argv 后直接调用并透传退出码；当构建不满足条件时（非 Linux、缺少 libcap 头文件、vendored 源码缺失）会 panic 并提示 “bubblewrap sources expected at codex-rs/vendor/bubblewrap (default)”。这说明本仓库走的是非 setuid、依赖 user namespace 的标准姿态。
• 参数构造即安全策略：codex-rs/linux-sandbox/src/bwrap.rs 的 create_bwrap_command_args 是整个 Linux 沙箱安全模型的落点——它根据读写权限策略生成 --bind、只读子路径绑定、不可读根目录屏蔽等具体参数（如 第 567-L569 行附近 对挂载根做同名 --bind）。这正体现了原文档第 3、4 条：沙箱边界强弱由参数决定，由构造参数的这一层代码负责。
• 二进制可信链：codex-rs/linux-sandbox/src/bundled_bwrap.rs 在解析内置 bwrap 可执行文件（例如安装目录下的 codex-resources/bwrap）时，会先用 verify_digest 对照内置的期望 SHA-256 摘要再使用，避免执行被篡改的 setuid 无关沙箱工具；第 48 行 还借助 /proc/self/fd/<fd> 路径在沙箱内引用该文件。

五、评估 bwrap CVE 与部署的实操结论

综合本文档声明与仓库实现，可得出三条可操作的结论：

1. 确认构建形态：vendored 源码（meson_options.txt）默认 support_setuid=false，即当前仓库的 bwrap 属于“拒绝以 setuid 运行”的推荐构建形态；评估 CVE 时，凡是标注“仅影响 setuid 模式”的条目可以安全忽略。
2. 区分漏洞归属：遇到 bwrap 相关漏洞报告时，先按原文档判据分类——是否突破“不比 user namespace 更弱”的等价性承诺（若是，属 bwrap 本体，走容器生态披露政策）；还是调用方参数设计问题（如终端设备暴露、TIOCSTI 类 ioctl，则归属调用方框架）。
3. 审计传参层：由于沙箱强度完全由 bwrap 参数决定，对本仓库而言真正的审计对象是 codex-rs/linux-sandbox 中的参数构造逻辑与权限策略映射，而非 bwrap 二进制本身。

需要说明的适用前提：以上结论基于本仓库 vendored 的 bubblewrap 0.11.2 源码（meson.build）；若上游版本演进移除了 setuid 支持（README 已预告该方向），本文引用的 setuid 相关条款将随之简化。