1.1 进程、容器与微 VM：三级实操对比
1.1 进程、容器与微 VM：三级实操对比
本节摘要：隔离的本质是「在你执行的代码与宿主内核之间垫几层」。本节按垫层的厚度过一遍三级：进程级用 seccomp 与能力裁剪在系统调用入口设卡，最轻但边界是「策略」而非「物理墙」；容器是性价比默认项——Docker 默认已带 seccomp 与能力裁剪两道软边界，但它与宿主共享内核，runc 历史逃逸漏洞（官方 CVE 记录）就是它的天花板，必须靠加固参数收敛；微 VM 有两条路线，gVisor（runsc）在用户态实现一个内核拦截系统调用，Firecracker 干脆给每个 VM 一个独立内核。每级给出最小实操示例与「挡得住 / 挡不住」清单，最后汇总成一张三级对照表，作为 1.2 节决策树的事实基础。
学习目标
- 用「与宿主内核的距离」说明三级隔离的本质差异。
- 说出 Docker 默认自带的软边界及其失效条件。
- 区分 runsc（用户态内核）与 Firecracker（独立内核）的原理与数字特征。
- 会查、会用三级对照表完成初步比较。
一、三级谱系总览：垫了几层，就硬几分
第 0.1 节的四类攻击面里，「内核漏洞」这一类决定性地拉开了三级差距：
- 进程级：进程与宿主之间没有任何独立边界，只有内核入口处的过滤策略（seccomp / capabilities）。策略挡住的是「调用了不该调的系统调用」，挡不住「内核自身被攻破」。
- 容器：命名空间与控制组给出文件系统、进程、网络的视图隔离，但系统调用仍直达宿主内核——边界是「共享内核上的约定」。
- 微 VM：应用根本接触不到宿主内核（runsc 拦截转发，或 Firecracker 给独立内核），内核漏洞攻击打到的是隔离层。
（文字流程图）系统调用路径对比 进程级： 应用 ──▶ seccomp 过滤 ──▶ 宿主内核 （策略卡） 容器： 应用 ──▶ 默认 seccomp+能力裁剪 ──▶ 宿主内核 （约定边界） gVisor： 应用 ──▶ Sentry（用户态内核）──▶ 受控宿主接口 （拦截转发） Firecracker： 应用 ──▶ VM 独立内核 ──▶ KVM 虚拟化边界 （物理边界）
二、进程级：seccomp 与能力裁剪（最轻）
适合「自己的代码、只防手滑」的场景。Linux 上最顺手的载体是 systemd 单元属性：
# systemd_run_sandbox.sh —— 进程级沙箱：一次性进程套上系统调用过滤与文件保护（写法示意，以 systemd 官方手册为准） systemd-run --wait --pipe \ --property=SystemCallFilter=~@privileged @resources \ --property=ProtectSystem=strict \ --property=ProtectHome=yes \ --property=PrivateNetwork=yes \ --property=MemoryMax=512M \ python3 analyze.py
挡得住：误操作写系统目录、提权系统调用、意外联网、内存失控。挡不住：内核漏洞利用（过滤的是调用入口，不是内核实现）、以非 root 身份仍可读的全部文件（ unless 另加 RestrictFileSystems 一类属性）。
⚠️ 定位提醒：进程级对 Agent 只够格做「锦上添花」，不能做主防线——因为 Agent 的命令来源不可信（第 0.1 节），它面对的不是手滑，是刻意绕过。进程级规则见《企业安全实践与攻防知识库》中系统加固相关条目。
三、容器：Docker 默认给了什么，还缺什么
Docker 默认并非裸奔：官方默认 seccomp 配置会屏蔽一批高危系统调用，默认能力集也做了裁剪（官方文档）。但默认值挡不住三件事：以 root 运行带来的横向能力、对敏感宿主路径的挂载（-v /:/host 一挂全部归零）、以及共享内核这一结构性风险——runc 曾出现可导致容器逃逸的漏洞（CVE-2019-5736 覆盖宿主 runc 二进制、CVE-2024-21626 文件描述符泄漏，均为官方 CVE 记录）。
所以「容器级」的真正含义是「加固容器」，默认项只是起点。第 2.1 节会给完整的四道边界（只读根、断网、能力全裁、资源限额），此处先记结论：容器挡得住前三类攻击面（文件系统、网络、资源）的绝大部分，挡不住内核漏洞这一类——这正是 2.2 节 gVisor / Firecracker 存在的理由。
⚠️ 除默认值不足外，还有一类「主动拆墙」参数：
--privileged、--pid=host、--net=host会把默认边界也一并拆掉。Agent 沙箱的运行命令里出现任何一个，都应视为配置事故直接打回。
四、微 VM：gVisor 与 Firecracker 两条路线
gVisor（runsc）——用户态内核。 runsc 实现了一个称为 Sentry 的用户态「内核」：应用发出的系统调用被 Sentry 截获并在用户态重新实现，再以受控方式与宿主交互。内核漏洞攻击打到的是 Sentry 的重新实现，而不是宿主内核。关键数字：典型容器启动延迟约 50~100 毫秒（社区资料，2026）；运行开销与负载高度相关——系统调用密集型任务明显变慢，计算密集型接近原生（社区实测，量级参考）。生产案例：GKE Sandbox 用它跑不可信负载（官方资料）。兼容性注意：多数常用系统调用已支持，冷门 ioctl、ptrace 类仍有缺口（官方兼容性文档）。
💡 预算口径：runsc 的性能税主要交在系统调用密集段——把 I/O 密集步骤移出沙箱或做批量化，往往比换隔离级别更划算。
Firecracker——每 VM 一个独立内核。 由 AWS 开源的极简 microVM：最小设备模型、KVM 虚拟化。关键数字：启动不超过 125 毫秒、每 VM 内存开销小于 5 MiB、每秒可创建约 150 个 microVM（均为官方规格数据）。AWS Lambda 与 Fargate 基于它运行（公开资料）。运维代价：要自备内核镜像与 rootfs、自己管网络（tap 设备），配套 jailer 做宿主侧隔离（注：jailer 的去留以官方仓库最新讨论为准）。
💡 一句话区分：runsc 是「同一栋楼里换了个门卫，逐个检查访客」；Firecracker 是「每户独立门禁，整栋楼结构隔离」。前者接入成本低（Docker 换个 runtime 参数），后者隔离更彻底（连内核都换）。
五、三级对照表（一张表定初选）
| 维度 | 进程级（seccomp / 能力裁剪） | 容器（加固 Docker） | 微 VM（runsc / Firecracker） |
|---|---|---|---|
| 内核暴露 | 直达宿主内核 | 共享宿主内核（结构性风险） | 不直接触宿主内核 |
| 文件系统逃逸 | 靠属性约束，粒度粗 | 只读根 + 白名单挂载，收敛好 | 同左，且宿主接口受控 |
| 网络外联 | 可断（PrivateNetwork） | 可断（--network none） | 可断，且网络栈独立 |
| 资源耗尽 | 可限（MemoryMax 等） | 可限（--memory/--cpus/--pids-limit） | 可限，外加 VM 级硬顶 |
| 启动开销 | 近乎为零（示意） | 数百毫秒（示意） | runsc 约 50~100 毫秒（社区）；Firecracker 不超过 125 毫秒（官方） |
| 运行开销 | 无感 | 接近原生 | 系统调用密集型负载有感（社区实测） |
| 运维复杂度 | 最低 | 低（Docker 生态） | 中（runsc）到高（自管内核 / rootfs / 网络） |
| 适用 | 自有代码防手滑 | 单租户、可信度中等的 Agent 负载 | 任意执行型、多租户、不可信负载 |
⚠️ 表里的开销数字属性混杂（官方 / 社区 / 示意），做容量规划请以自己的负载实测为准；本书第 2 章所有落地代码都可以直接当压测脚手架。
（文字流程图）选型直觉：负载可信度越低、隔壁数据越值钱 ──▶ 垫层就该越厚。
（文字流程图）选型直觉：负载可信度越低、隔壁数据越值钱 ──▶ 垫层就该越厚。
本节要点回顾
- 三级的本质是「应用与宿主内核之间垫几层」：策略卡（进程级）→ 共享内核上的约定（容器）→ 拦截转发或独立内核（微 VM）。
- Docker 默认有 seccomp 与能力裁剪两道软边界，但挡不住 root、危险挂载与内核漏洞；容器级必须加固才有意义。
- runsc 与 Firecracker 的区别：用户态内核逐调用拦截（接入易）vs 每 VM 独立内核（隔离彻底、运维重）。
- 对照表是初选工具；精确到「我该选哪级」要引入 Agent 的能力面与数据敏感度——这正是下一节。
三级的长处短处已经摆上桌面，但「我都想要最硬的」不是答案——微 VM 的运维成本会吃掉小团队的迭代速度。下一节用两个提问和一棵决策树，把选择变成一次五分钟的工程判断。