第 24 章：底层工程导读——墙壁、门禁与接线方式

bubblewrap：工具不会自动替你写安全策略

bubblewrap 的 README 特别强调：它是构造沙箱的工具，不是一套已经定义好策略的完整沙箱；保护程度取决于调用者传入的参数。[19] 这是理解整个领域的一句话。

它可以建立新的挂载视图，选择哪些目录可见、哪些只读；也可以使用进程、用户、网络等命名空间，并接入 seccomp。外层框架需要把“只读输入、只写输出、不能联网”的意图转换成相应配置。

因此读到 sandbox-runtime 使用 bubblewrap 时，下一步应看它怎样构造参数，而不是在脑中直接写下“已安全”。给程序挂载过多目录、暴露不合适的 socket，仍会扩大能力。本书不让你照抄一条通用 bwrap 命令去执行陌生代码；先从官方示例认识每个可见路径的用途。

nsjail 是 Linux 进程隔离工具，文档介绍 namespaces、cgroups、资源限制与 seccomp 策略，并支持配置文件。[20] 相比托管平台，你会更直接地看到权限政策由哪些字段组成。

可以从三个问题读配置：进程看得见什么文件？使用什么身份与网络空间？最多运行多久、用多少资源？特别区分 wall time 与 CPU time：等待外部响应会消耗实际时间，但未必持续消耗 CPU。

它的运行模式和平台前提也影响行为。不要把某个官方演示中的高权限 Docker 启动方式直接移植为生产建议；示例可能是为了演示嵌套机制，实际部署需要重新明确宿主机和容器的边界。

Kata 的 README 把它定位为以轻量虚拟机提供工作负载隔离，并与容器使用方式衔接的项目。[21] 组件包括容器管理侧的 runtime、客体中的 agent，以及可配置的 hypervisor 等。

可以把它理解成接线：上层仍提出容器工作负载，运行时把它安排进虚拟机，客体 agent 再建立和管理执行环境。Kubernetes 的 RuntimeClass 只是选择入口，真正的隔离取决于节点安装、配置与实际创建的环境。

不要推导成“每个普通进程都有一台独立 VM”。隔离单位、Pod 内共享关系和宿主资源需要查具体架构。官方提供主机能力检查入口，说明硬件虚拟化条件也是部署契约的一部分。

Firecracker 仓库 README 解释 KVM、精简设备模型与 microVM，还介绍了面向生产的 jailer 和宿主机配置资料。[22] 它提供虚拟机监视器及管理接口，但并不自动等于一套完整的 Agent 服务。

SPACE 等工程还要解决模板、网络、节点选择、命令输出、身份与清理。读源码地图时，应把“平台用了 Firecracker”和“平台所有问题都由 Firecracker 保证”区分开。README 也明确提醒整体安全依赖正确配置的 Linux 宿主机。

结合前文已核对的 gVisor 官方架构文档，重点理解应用内核、系统调用处理和兼容性。[5] 它不是完整硬件虚拟机，也不能只当作一份 seccomp 调用过滤表。

同一份分析程序可能在普通容器、gVisor 与 microVM 中运行，但文件操作密集、网络密集、特殊系统调用的任务会呈现不同兼容性与开销。先检查真实依赖，再做性能判断。