容器与沙箱知识文档

简约无双
  2026-08-31 11:47 2026-08-31 11:47 创建   2026-09-12 23:34:42 2026-09-12 23:34:42 更新      7.4k 字  29 分钟  

[toc]

一、基础概念与共同地基

1.1 容器 vs 沙箱：边界在哪里

  • 容器（Container）：操作系统级虚拟化，共享宿主机内核，隔离文件系统、网络、进程、用户等资源视图。主打完整应用的运行——提供一个可用的运行环境。
  • 沙箱（Sandbox）：广义的隔离环境。通过限制程序的权限、I/O、系统调用来约束其行为。侧重不可信代码的安全执行——重点是”不许做什么”。

核心认知：两者边界高度重叠（容器本身就是一种”重型沙箱”），区别不在技术栈，而在设计意图——容器的第一目标是「让程序能跑起来」（提供环境），沙箱的第一目标是「让程序跑不出圈」（限制行为）。

1.2 隔离强度的五层谱系

整个隔离技术谱系从弱到强分成五层，是理解全部工具的骨架：

层次 代表技术 是否共享宿主内核
L1 权限裁剪 Landlock、seccomp、Capabilities、AppArmor/SELinux 共享
L2 进程沙箱 Firejail、Bubblewrap、nsjail、Isolate 共享
L3 应用容器 Docker、Podman、containerd、CRI-O 共享
L4 系统容器 LXC、LXD/Incus、systemd-nspawn 共享
L5 硬件虚拟化 Firecracker、Kata、QEMU-KVM 独立

最重要的技术分野：是否共享宿主机内核。共享内核意味着所有容器共享同一个攻击面，一个内核漏洞即可导致”容器逃逸”；独立内核则不存在这个隐患。运行”完全不可信”代码时，共享内核方案（L1~L4）在理论上都不如独立内核方案（L5）可靠。

1.3 共同地基：Linux 内核隔离

所有上层容器/沙箱都是以下原语的不同组合：

  • namespaces（命名空间）：提供”视图隔离”——pid（进程独立编号）、mnt（独立根文件系统）、net（独立网卡/IP/端口栈）、user（UID/GID 映射，容器内 root 在宿主机只是普通用户）、uts（独立主机名）、ipc（独立进程间通信）。
  • cgroups（控制组）：提供”资源限制”——CPU、内存、磁盘 IO、进程数、文件句柄；cgroups v2 是当前主流。
  • Capabilities（能力裁剪）：把传统 root 的”全权”拆成几十个细粒度能力（CAP_SYS_ADMIN、CAP_NET_ADMIN 等），移除程序不需要的能力。
  • seccomp-bpf（系统调用过滤）：通过 BPF 程序对系统调用做黑白名单过滤，是进程的”最后一道防线”。Firejail 用它做默认过滤；nsjail 用 Kafel 语法编写策略；Docker/K8s 有默认 profile。
  • LSM（强制访问控制）：
    • AppArmor：基于路径的 MAC，配置直观，Ubuntu/Kubuntu/openSUSE 默认；Snap 依赖它。
    • SELinux：基于标签的 MAC，策略更严格复杂，RHEL/Fedora/CentOS 默认。
    • Landlock（较新的可堆叠 LSM）：最大特点是无需特权——任意非特权进程可自我限制，且限制只能收紧、不能放宽，并被子进程继承。版本按内核 ABI 分级：
      • ABI 1（5.13）文件系统访问控制；ABI 2（5.19）跨目录重命名/链接；ABI 3（6.2）truncate；ABI 4（6.7）网络限制；ABI 5（6.10+）设备 ioctl。
      • 已被 Ubuntu 20.04+、Debian、Fedora 35+、Arch、RHEL 9.6+、ChromeOS、WSL2 默认启用；OpenSSH、systemd、suricata、pacman、Cloud Hypervisor、Firejail 与 setpriv 也已集成。
      • Landlock 与 seccomp 互补：seccomp 管”能调用哪些系统调用”，Landlock 管”能碰哪些资源”。
  • no_new_privs：PR_SET_NO_NEW_PRIVS 标记，禁止进程通过执行 setuid 程序获得更高权限。Bubblewrap 默认启用；Firejail 可通过 force-nonewprivs yes 强制开启。

二、容器方案

2.1 Docker

  • 定位：最通用的容器工具，覆盖开发、桌面、服务器全场景，工业事实标准。
  • 架构：依赖 dockerd 守护进程（历史上以 root 运行，后期加入 rootless 模式），底层调用 containerd → runc。
  • 优势：生态最大（Docker Hub）、Dockerfile 可复现构建、Docker Compose 编排、K8s 生态兼容。
  • 风险：加入 docker 组等效于免密 root（官方文档承认的事实）；镜像仓库安全性参差。
  • 适用：微服务、应用打包分发、CI、与团队既有 CI/CD 对齐。

2.2 Podman

  • 定位：无守护进程（daemonless）的 Docker 替代品，命令行兼容 Docker（可 alias docker=podman）。
  • 核心优势：rootless 优先，默认以普通用户身份运行，无常驻 root 守护进程，攻击面显著小于 Docker；原生支持 Pod（一组协同容器共享网络命名空间），契合 K8s 模型。
  • 镜像：二进制兼容 Docker 镜像。
  • 注意：在 Fedora 上需注意 SELinux，有时要 --security-opt label=disable。
  • 适用：追求安全的单机构容器运行、Kube 风格多容器协同、不需要 root 的开发环境（Distrobox 的推荐后端）。

2.3 containerd

  • 定位：底层容器运行时，不是给终端用户直接用的。
  • 负责镜像拉取/存储、容器生命周期、网络与存储接口，实际创建容器下沉到 runc。
  • Kubernetes 默认运行时（配合 CRI 插件）；Docker 自身也构建在它之上。

2.4 CRI-O

  • 定位：专门为 Kubernetes 设计的轻量级容器运行时，只实现 CRI，不做 K8s 用不到的功能。
  • 相比 containerd 更精简，攻击面更小，是 Red Hat / OpenShift 生态的默认选择。

2.5 nerdctl

  • 定位：containerd 的配套 CLI，语法刻意兼容 docker 命令，让没有 Docker 的环境获得熟悉的命令行体验。
  • 支持 rootless、compose、lazy-pulling（镜像按需拉取）等 containerd 原生特性。

2.6 runc / youki（OCI 低层运行时）

  • runc：OCI 运行时参考实现（Go 编写），是 Docker / containerd / CRI-O / Podman 共同的最底层执行器。
  • youki：Rust 编写的低层容器运行时，兼容 OCI 规范，可作 runc 替代，内存安全语言降低漏洞风险。
  • 调用链全景：docker/nerdctl/podman（CLI）→ containerd/CRI-O（高层运行时）→ runc/youki/runsc(gVisor)/kata-runtime（低层 OCI 运行时）→ 内核 namespaces+cgroups。

2.7 LXC（Linux Containers）

  • 定位：Linux namespace / cgroups 的原生用户态工具集，直接操作内核隔离接口，属于底层组件。
  • 命令形态：全部以 lxc- 开头——lxc-create、lxc-start、lxc-stop。
  • 核心原理：依靠内核四大隔离机制（pid / mnt / net / user namespace）+ cgroups 限制资源；user namespace 默认非特权，容器 root 在宿主机只是普通用户，逃逸风险极低。
  • 优点：极致轻量、无多余守护进程、可高度自定义、适配老旧系统。
  • 缺点：配置繁琐、无镜像仓库、无快照/集群、命令繁杂，只适合资深运维做定制环境。
  • 使用场景：极少单独部署，一般被 LXD/Incus、LXCFS 封装；仅用于嵌入式系统、定制隔离环境开发。

2.8 LXD / Incus（系统容器管理工具）

  • 定位：LXD 是 Canonical 基于 LXC 开发的上层管理守护进程；Incus 是 2023 年 LXD 之父 Stéphane Graber fork 出的社区分支。
  • 架构：Daemon → 调用 liblxc 创建容器 → REST API；用户通过 lxc/incus CLI、WebUI、SDK 管理。
  • 核心特性：镜像化管理（全球镜像服务器秒级创建完整系统容器）、默认 user namespace 非特权容器、强大存储后端（dir/btrfs/ZFS/LVM 写时复制，适配 Kubuntu 的 Btrfs）、完整网络管理（桥接/NAT/VLAN）、快照与实时迁移、集群能力、同时支持容器+虚拟机。
  • 与 Docker/Podman 关键区别：系统容器运行完整 OS（systemd、多服务长期运行），隔离强于应用容器；应用容器偏临时/可丢弃。

2023–2026 重大变化：Incus 分支

2023 年 Canonical 要求所有 LXD 贡献者签 CLA，将代码收归自家。社区随之迁移到 Incus。
2026 年现状对比：

维度 Incus LXD
许可证 Apache 2.0 Apache 2.0 / AGPLv3 双许可
治理 社区（Linux Containers 项目） 企业（Canonical），需签 CLA
打包 原生进入 Debian 13+/Ubuntu 24.10+/Fedora 40+/openSUSE/NixOS 主仓库 仅通过 Snap 分发
独有特性 支持 OCI 实例，与系统容器/VM 统一管理；OVN 网络更成熟 Ubuntu Pro / MAAS / Landscape / Juju 集成
迁移 lxd-to-incus 原地迁移工具 —

结论：除非已付费使用 Ubuntu Pro/MAAS/Landscape，2026 年新建部署直接上 Incus（命令 lxc→incus，lxd init→incus admin init）。

1
2
3
4
5
sudo apt install incus
sudo adduser $USER incus-admin && newgrp incus-admin
incus admin init
incus launch ubuntu:24.04 mybox
incus launch ubuntu:24.04 myvm --vm

2.9 systemd-nspawn

  • 定位：systemd 自带的极简系统容器（apt install systemd-container），”真正管用的 chroot”——自动挂载 /proc、/dev，自动配网络。
  • 特性：无守护进程、无配置文件（可选 .nspawn unit）；深度集成 machinectl / journald；--ephemeral 临时 overlay 容器退出即弃；支持完整 init 启动（-b）。
  • 劣势：无集群、无快照（仅文件系统级）、无镜像仓库生态、网络功能有限。
  • 最佳实践：打算用 systemctl 开机自启、且永远不需要迁移或 CLI 快照 → nspawn 就够；否则用 Incus。
1
2
3
sudo debootstrap bookworm /var/lib/machines/mydebian
sudo systemd-nspawn -D /var/lib/machines/mydebian -b
sudo systemd-nspawn -D /var/lib/machines/mydebian --ephemeral

2.10 Distrobox

  • 定位：上层封装（一组 POSIX shell 脚本），底层调 Podman 或 Docker，本质是”美化版 Podman 容器”，一键安装并切换不同发行版。
  • 设计理念：Docker 容器是”牲畜”（cattle，可随意销毁）；Distrobox 容器是”宠物”（pets）——家目录/dotfiles/配置持久化，你会认真维护它。
  • 核心能力：一行命令创建任意发行版；自动挂载家目录、X11/Wayland、音频、GPU；distrobox-export 把容器内 GUI 应用导出到宿主菜单；distrobox assemble 用 INI 声明式批量定义容器，可纳入 dotfiles 版本管理。
  • 优点：跨发行版自由、与宿主机高度集成、支持 GPU/GUI、几乎零开销，在不可变发行版（Silverblue/SteamOS/NixOS）上”突破限制”的利器。
  • 缺点：网络隔离弱，不适合部署对外服务/独立服务器；与宿主机深度集成意味着容器突破后果更严重。
1
2
3
4
distrobox create --name arch --image archlinux:latest
distrobox enter arch
distrobox-export --app chromium
distrobox assemble create --file distroboxfile

2.11 Toolbx（Fedora）

  • 定位：Fedora 官方容器化开发工具（Fedora 34，2021），比 Distrobox 更早更专一。

  • 关系：作者有交集（Distrobox 作者也是 Toolbx 贡献者）；Toolbx 是 Fedora 专属”限定版”，Distrobox 是”泛化版”。

    维度 Toolbx Distrobox
    目标发行版 Fedora Silverblue / 不可变系统 所有主流发行版
    容器后端 仅 Podman Podman 或 Docker
    预装情况 Fedora 原子版开箱自带 需自行安装

2.12 Devbox

  • 基于 Nix 的项目级开发环境工具，用 devbox.json 声明依赖，生成可复现的隔离 shell。与 Distrobox 的区别：按项目而非按机器，依赖 Nix 包管理而非发行版镜像。

三、沙箱方案

3.1 Firejail

  • 定位：轻量级 Linux 用户态沙箱，用 namespaces + seccomp-bpf + Capabilities + AppArmor 实现进程隔离，无需改内核、无守护进程、开箱即用。
  • 关键区分：不创建完整操作系统，直接包裹宿主机上已有的程序进行限制。
  • 核心原理：① 新建独立 PID/挂载/网络/用户命名空间；② Capability 裁剪；③ seccomp 黑白名单；④ 文件系统隔离（private/private-bin/read-only/blacklist）；⑤ 网络控制（禁用/回环/隔离）。
  • 优势：极简一条命令（firejail firefox）、资源开销极低、支持普通用户、内置 1000+ 软件预设、可保护密钥。
  • 局限性：共享宿主机文件系统主体，配置不当有逃逸风险；不适合长期服务；无快照/克隆；默认配置偏向可用性。

Firejail 是 SUID 程序

它必须以提升的权限运行才能建沙箱，本身是攻击面。历史累计 18 个 CVE，多为本地提权：

  • CVE-2022-31214（CVSS 7.8）：--join= 缺陷可在未启用 NO_NEW_PRIVS 时于 mount namespace 内运行 setuid-root 程序提权；缓解：no join + force-nonewprivs yes。
  • CVE-2021-26910（7.8）：OverlayFS TOCTOU 竞态致任意文件写入。
  • CVE-2020-17367/17368：--output shell 元字符注入致命令注入。

维护者自评：攻击者在沙箱内获得完整代码执行后，约 80~90% 的 profile 可被逃逸。

正确姿势：适合隔离无自带沙箱的程序（evince/libreoffice 等文档查看器、PDF 解析器、媒体播放器、未知二进制）；不要再给浏览器套 Firejail——现代浏览器 broker 沙箱更严密，外面套弱边界反而可能干扰它。浏览器改用 AppArmor profile（如 apparmor.d 项目）。

版本：2026-03 发布 0.9.80（新 seccomp-bpf 引擎、--x11 默认 Xephyr、隐藏 PID 1、Firefox 新 XDG 支持）；0.9.74（2025-03）起加 Landlock 实验性支持。

  • 命令：

    1
    2
    3
    4
    5
    6
    firejail firefox                                   # 浏览器见上方说明，建议改用 AppArmor
    firejail --net=none python untrusted_script.py    # 无网络（原文笔误 --noprogram 已更正为 --net=none）
    firejail --private bash                            # 私有家目录，退出即弃
    firejail --blacklist=~/.ssh code
    firejail --net=none --private evince suspicious.pdf          # Firejail 甜区
    firejail --net=none --private --caps.drop=all ./unknown-binary
    1
    2
    3
    # /etc/firejail/firejail.config 安全加固
    force-nonewprivs yes
    no join

3.2 Bubblewrap (bwrap)

  • 定位：底层沙箱构建工具，单二进制几十 KB，Flatpak 整个沙箱体系基于它实现。
  • 设计哲学：不提供任何现成规则，只搭空白命名空间环境，由使用者手动指定挂载与权限。
  • 核心原理：默认全新挂载命名空间、根目录是临时 tmpfs（退出即弃）；手动把 /usr、/proc 等只读绑定进去，其余不可见；支持全部命名空间隔离、PR_SET_NO_NEW_PRIVS、seccomp；普通用户即可运行（依赖 user namespace）。
  • 特点：极度轻量、易审计；原生无预置规则，几乎不会手动直接用；无内置资源限制；强制禁止 setuid 提权；无 SUID 攻击面（对比 Firejail 的优势）；主要作 Flatpak 底层组件。
1
bwrap --unshare-all --ro-bind /usr /usr --proc /proc bash

3.3 Flatpak

  • 定位：应用分发 + 沙箱一体化的 Linux 桌面包格式，自带隔离。
  • 底层：Bubblewrap（namespaces）+ seccomp（禁用 ptrace 等）+ XDG Desktop Portal。
  • 权限模型：默认只能看自身目录和隔离 home；默认只有 loopback 网络；通过 Portal 门户（D-Bus）中介访问宿主资源——文件选择器让用户运行时挑文件，只授权那一个具体文件，比 Snap 更细粒度。
  • 生态：Flathub 社区治理，2025 年超 3200 应用、4.33 亿次下载；共享 runtime + OSTree 去重。
  • 冷启动：Firefox 原生 ~1.2s / Flatpak ~1.8s / Snap ~3.5s。
  • 后门：--filesystem=host 权限会彻底关闭文件系统沙箱，装应用前先看 manifest 权限声明。

3.4 Snap

  • 定位：Ubuntu 系自带通用包格式，内置沙箱。
  • 底层：AppArmor（基于路径的 MAC）+ seccomp + cgroups，策略表达力强（可管 capability/mount/ptrace/signal/dbus）。
  • 三种 confinement：
    • strict：真正隔离，只能通过 interface 访问显式授予资源（Snap Store 默认）
    • devmode：为开发关闭隔离，仅记录日志
    • classic：完全等同传统 deb 包，无任何沙箱
  • 现实问题：Canonical 哲学导致大量 snap 申请 broad permission（如 home 可读）甚至 classic confinement，IDE/开发工具常跑 classic 模式，沙箱收益归零。所有 snap 必须走 Canonical 控制的 Snap Store；snapd 常驻；SquashFS 解压是冷启动瓶颈。

3.5 AppImage

  • 事实说明：AppImage 完全没有沙箱——解包到临时目录后以当前用户完整权限运行，可访问 Documents、.ssh、整个家目录、所有挂载文件系统。优势是单文件便携、无守护进程、无需安装；代价是零隔离、无内置更新。从网上下载来源不明的 AppImage 直接运行，等同于运行不受限二进制——此时应主动套一层 Firejail。

3.6 nsjail

  • 定位：Google 开发的专用不可信代码沙箱，在线 OJ 判题、CTF、执行外部恶意脚本的标准工具。
  • 技术栈：namespaces（PID/挂载/网络/用户/UTS/IPC 全部独立）+ cgroups + seccomp-bpf（Kafel 语法）。
  • 特点：protobuf 配置极强、隔离等级高于 Firejail/bwrap、可独立搭建隔离网络/MACVLAN、无多余功能攻击面极小、默认需要 root。
  • 三种运行模式：单次执行、TCP 监听服务、循环重启；自带资源超时限制。
  • 适用：OJ、CTF、模糊测试、运行来源不明的 AI Agent 脚本、第三方不可信二进制——容器之外安全性最高的轻量级方案。
1
nsjail --time_limit=30 --mem_limit=100M -- python untrusted_code.py

3.7 Isolate

  • 定位：由 IOI（国际信息学奥林匹克） 官方使用、Martin Mares 与 Bernard Blackham 编写（GPLv2），专为编程竞赛设计。
  • 三进程模型：Keeper（root，父命名空间，监控超时）→ Proxy（调用者 UID，充当子命名空间 init）→ Inside（沙箱专属 UID，执行目标）。两管道通信（错误/状态）。
  • 工作流程：--init → 填充文件 → --run -- program → --cleanup。
  • 资源限制：CPU 时间 -t、墙钟 -w、内存 -m/cgroup --cg-mem、文件大小 -f、进程数 -p、栈 -k、磁盘 -q。
  • 系统调用限制（精妙处）：一般不让进程”没对象可操作”，只对内核未妥善命名空间化、可能跨沙箱泄漏的对象用 syscall_flags 位掩码禁用：flag 1 keyrings / flag 2 AF_VSOCK / flag 4 inode 文件锁 / flag 8 io_uring / flag 16 legacy 架构（默认全开）。
  • 部署：default.cf 配置 box_root/cg_root/first_uid/first_gid/num_boxes（每个沙箱分配唯一 UID 保证并发隔离）；生产环境常见 Docker 容器内再跑 isolate。
1
2
3
isolate --cg --init --box-id=0
isolate --cg --box-id=0 --time=2 --wall-time=10 --mem=262144 --run -- ./solution
isolate --cg --box-id=0 --cleanup
  • nsjail vs Isolate：两者定位接近，nsjail 更通用可独立搭网络；Isolate 更专注竞赛判题，资源计量（meta.txt）更精细。

3.8 Firecracker

  • 定位：AWS 开发开源（Apache 2.0）的微型虚拟机（MicroVM），介于容器和 QEMU-KVM 之间，基于 KVM，砍掉冗余设备，面向瞬时启动、强隔离、轻负载。
  • 核心原理：依托 KVM 硬件虚拟化，每个实例独立内核，不存在内核逃逸风险（容器最大隐患）。仅保留 virtio-net/block/vsock、串口控制台、最小化键盘控制器。
  • 特性：极速启动（官方 125ms 内，视配置 100200ms）；强安全隔离（进程 jailer/资源限制/最小攻击面）；极低内存（单实例 < 5 MiB，单主机创建速率 ~150 台/秒）；API 驱动（仅 HTTP REST，无开箱 CLI）；只读根文件系统+最小内核；不支持持久化常驻。
  • 优势：VM 级隔离 > LXD/Docker/Firejail/nsjail；启动远快于传统 KVM；代码约 5 万行 Rust vs QEMU 近 200 万行 C；原生 CPU/内存硬隔离；所有支持 KVM 的 Linux 可部署。
  • 局限：使用门槛高（需上层封装）；需预编译精简内核+rootfs；不支持快照/图形/USB/复杂网络；不支持 GPU/USB/PCI 直通；依赖 VT-x/AMD-V；仅 Linux、需 /dev/kvm。
  • 上层工具：firecracker-containerd、Weave Ignite（类 Docker 体验）、Kata（底层可选 Firecracker，默认已是 Cloud Hypervisor）。
  • 场景：Serverless（AWS Lambda/Fargate 底层）、OJ、AI Agent 隔离、多租户、CI。

关于 “kvmtool + microvm”：指”极简 VMM + MicroVM”这一类方案，Firecracker 是最著名实现，同类还有 Cloud Hypervisor（现为 Kata 默认后端）。

3.9 gVisor（Google）

  • 定位：用户态内核方案（安全容器运行时），在容器与宿主内核间加边界。
  • 原理：核心组件 Sentry（Go 编写，内存安全）拦截沙箱内进程所有系统调用，在用户空间自行处理，不转发宿主内核；配套 Gofer 作独立文件系统代理，I/O 经其中转最小权限。
  • 不是虚拟机：不启动独立 guest kernel。
  • 运行模式：Systrap（默认，seccomp 纯软件拦截，无需硬件虚拟化，x86/ARM 通用）/ KVM（硬件虚拟化，性能更高、隔离更强）。
  • 性能：启动毫秒级；系统调用开销约 10~30%；用户态 netstack 是网络瓶颈；CPU 密集且系统调用少的应用开销极小。
  • 兼容性限制：约 90% 系统调用支持，不支持 ptrace/perf/eBPF/部分 ioctl；沙箱内 strace/gdb 部分失效。
  • 集成：Docker/containerd/K8s 的直接可替换运行时（runsc），RuntimeClass 接入成本最低。
  • 适用：多租户 PaaS、共享主机、不可信镜像、CI/CD、FaaS；无需嵌套虚拟化的环境（多数云主机）首选。
1
docker run --runtime=runsc hello-world

3.10 Kata Containers

  • 定位：轻量虚拟机方案（安全容器运行时）。每个 Pod/容器跑在独立轻量 VM，自有 guest kernel，KVM 硬件强制隔离。Kata 是编排层——让 microVM 与容器工具链无缝协作。
  • VMM 后端：Cloud Hypervisor（默认，性能最佳） / Firecracker / QEMU。
  • 性能：启动 150300ms；I/O 接近原生；每实例约 128~256MB（VMM + guest kernel）。
  • 兼容性：完整 Linux 系统调用；支持 GPU/硬件直通（gVisor、Firecracker 都不支持）。
  • 适用：对抗性多租户、合规高的企业环境、需 GPU 直通、用到 gVisor 不支持的冷门系统调用。OpenInfra Foundation 托管。
  • 三选一：无嵌套虚拟化想最小改动换 runc → gVisor；要最强硬件隔离+完整调用+GPU → Kata；自建 Serverless 要极致启动/最小内存 → Firecracker。

纵深防御原则：安全容器运行时不能替代 seccomp/AppArmor/dropped capabilities/Pod Security Standards——它们是叠加层，保留原有加固，再为不可信负载额外加沙箱。

3.11 Windows Sandbox

  • 定位：Windows 10/11 Pro/Enterprise/Education 自带的一次性沙箱（Home 版不可用）。
  • 原理：基于 Microsoft Hypervisor 的轻量虚拟机，启动干净 Windows 桌面。
  • 特点：零配置、内核级强隔离、关闭即销毁、映射宿主目录需显式配置。
  • 局限：同时只能运行一个实例；会话间数据不持久。
  • 适用：试装来路不明软件、打开可疑附件、一次性测试。

3.12 Sandboxie-Plus

  • 沿革：2004 发布（最初沙箱化 IE）→ 2013 Invincea 收购 → 2017 Sophos 收购 → 2019 转免费 → 2020-04 Sophos 以 GPL-3.0 开源并停更 → David Xanatos fork 出 Sandboxie Plus 维护至今。
  • 原理：OS 级虚拟化，挂钩 NT 系统调用与注册表，深度绑定 Windows 架构，无 macOS/Linux 版。
  • Plus 增强：文件系统/注册表/IPC 根分别重定向、WFP 每沙箱防火墙、MarkOfTheWebBox 自动重定向下载文件。
  • 版本现状：Plus 1.16.9 / Classic 5.71.9（2026-01-02）；1.16.1 起弃 Win7/32 位；ARM64 支持属付费档。
  • 对比 Windows Sandbox：支持多沙箱并存、更细粒度、可用于 Home 版；但隔离弱于真 VM。

3.13 Shadow Defender

  • 真实定位：Windows “影子系统”，把磁盘写入重定向到虚拟层，重启全部还原。更像系统级还原卡/快照回滚工具，而非权限隔离沙箱——程序在影子模式仍以完整用户权限运行，只是写入不持久。对抗勒索/系统污染有效，但不能阻止数据外泄（程序照样能读文件、能联网上传）。

3.14 macOS App Sandbox

  • 定位：Apple 的应用强制沙箱，Mac App Store 上架必须启用。
  • 机制：通过 entitlements（授权声明） 声明所需权限，随代码签名发布，由内核 Seatbelt 强制执行。
  • 局限：只能约束自己的已签名 bundle（.app），无法沙箱化临时、内容未知的第三方命令。

3.15 sandbox-exec（Seatbelt 命令行）

  • 重要现状：已被 Apple 标记为 DEPRECATED。
  • 但 App Sandbox 不是合格替代品——只能沙箱化自己的 app bundle，无法提供 SBPL 级细粒度控制，也不适用单文件 CLI。“临时关住一条命令”目前无官方公开替代品。
  • 现实：Chromium、OpenAI Codex CLI、Claude Code 的 macOS 沙箱底层仍用 Seatbelt，macOS 14+ 仍可用。
1
2
3
4
sandbox-exec -f profile.sb command
sandbox-exec -p '(version 1)(allow default)' command
sandbox-exec -f profile.sb -D WORKING_DIR="$PWD" cmd
log stream --style compact --predicate 'sender=="Sandbox"'
  • 隔离强度：运行在共享内核之上，仅策略限制系统调用，隔离最弱，适合本地开发测试、限制个人工具联网、给 AI 助手加 guardrails；不足以承载真正恶意 payload。未来方向是微虚拟机（Apple Containerization / libkrun / microsandbox）。

四、横向对比与总结

4.1 全景对比总表

工具 分类 独立内核 隔离强度 启动速度 资源开销 上手难度 运行权限 快照/镜像 长期常驻
Landlock 内核 LSM 否 ★☆☆☆☆ 瞬时 零 高（需编程） 非特权 无 —
AppArmor/SELinux 内核 LSM 否 ★★☆☆☆ 瞬时 零 中（策略复杂） 需 root 配 无 —
AppImage 打包格式 否 ☆☆☆☆☆ 瞬时 低 极低 用户 无 否
Firejail 应用沙箱 否 ★★☆☆☆ 瞬时 极低 极低 用户（SUID） 无 否
Bubblewrap 底层沙箱 否 ★★☆☆☆ 瞬时 极低 高（无预设） 非特权 无 否
Flatpak 分发+沙箱 否 ★★★☆☆ 快 中 极低 用户 有 是
Snap 分发+沙箱 否 ★★★☆☆ 慢 中 极低 用户 有 是
nsjail 不可信代码沙箱 否 ★★★★☆ 瞬时 极低 中（protobuf） 通常需 root 无 否
Isolate OJ 沙箱 否 ★★★★☆ 瞬时 极低 中 需 root 无 否
Docker 应用容器 否 ★★★☆☆ 极快 低 低 root / docker 组 有 是
Podman 应用容器 否 ★★★☆☆ 极快 低 低 rootless 优先 有 是
Distrobox 开发容器 否 ★★☆☆☆ 毫秒级 极低 极低 用户 借 Podman 是
Toolbx 开发容器 否 ★★☆☆☆ 毫秒级 极低 极低 用户 借 Podman 是
systemd-nspawn 系统容器 否 ★★★☆☆ 快 低 低 root 无（文件系统级） 是
LXC 系统容器 否 ★★★☆☆ 极快 低 高 root 无 是
LXD / Incus 系统容器 否 ★★★★☆ 极快 低 中 root + user ns 有（优秀） 是
gVisor 安全运行时 间接 ★★★★☆ 毫秒级 中 低（drop-in） 非特权 复用 OCI 是
Kata Containers 安全运行时 是 ★★★★★ 150~300ms 中高 中（需 KVM） 需 /dev/kvm 复用 OCI 是
Firecracker 微 VM 是 ★★★★★ ~125ms 极低（<5MiB） 高（仅 API） 需 KVM 无 否
QEMU-KVM 传统 VM 是 ★★★★★ 数秒 高 中 需 KVM 有 是
Windows Sandbox Windows VM 是 ★★★★★ 数秒 中 极低 系统自带 无（一次性） 否
Sandboxie-Plus Windows 沙箱 否 ★★★☆☆ 快 低 低 用户 有 是
macOS Seatbelt macOS 沙箱 否 ★★☆☆☆ 瞬时 零 中（已废弃） 用户 无 —

4.2 分层总览

层级 隔离强度 举例
L0 无任何隔离 AppImage、直接运行的二进制
L1 权限裁剪 Landlock、seccomp、Capabilities、AppArmor/SELinux
L2 进程沙箱 Firejail（弱，SUID 有争议）→ Bubblewrap（底层，无策略）→ Isolate / nsjail（强，专业级）
L3 应用容器 Docker、Podman、containerd、CRI-O（共享内核，单进程）
L4 系统容器 LXC → LXD / Incus（完整 Linux 用户态）、systemd-nspawn
L4+ 安全容器运行时 gVisor（用户态内核）、Kata Containers（轻量 VM）
L5 微虚拟机 Firecracker（独立内核，毫秒级）
L6 传统虚拟机 QEMU-KVM、VirtualBox、VMware（独立内核，完整硬件）

4.3 场景化选型决策表

需求 首选 备选 理由
隔离浏览器、通讯软件 AppArmor profile 浏览器自带沙箱 浏览器自带沙箱更强，不应再套 Firejail
打开可疑 PDF / 文档 Firejail + --net=none --private nsjail 文档查看器无自带沙箱，正是 Firejail 甜区
运行来源不明的二进制 Firejail nsjail / Podman rootless 一条命令，瞬时完成
限制某个程序联网 firejail --net=none Firejail profile —
临时测试软件、不留痕迹 firejail --private systemd-nspawn --ephemeral 退出即销毁
切换发行版编译代码 Distrobox Toolbx（Fedora） 一行命令，与主机无缝互通
不可变系统上做开发 Distrobox Toolbx 突破只读根文件系统限制
搭建独立服务器环境（有独立 IP） Incus LXD 完整 systemd + 桥接网络
多套长期开发环境、要快照回滚 Incus / LXD KVM ZFS/Btrfs 快照秒级
在容器里再跑容器 LXD / Incus — 应用容器嵌套困难
只想跑单个应用/服务 Podman（rootless） Docker 无 root 守护进程
日常容器开发、K8s 对齐 Podman / Docker nerdctl —
运行未知 AI 脚本 / Agent（常规） Podman rootless Firejail 兼顾易用与安全
运行完全不可信代码（无嵌套虚拟化） gVisor nsjail 无需 KVM，drop-in 接入
运行完全不可信代码（最高安全） Firecracker + Ignite Kata Containers 独立内核，无逃逸风险
多租户不可信负载（生产） Kata Containers Firecracker 硬件隔离 + 完整编排
需要独立内核 / 跑 Windows / 内核模块 KVM 虚拟机 — 唯一选择
自建 Serverless / FaaS Firecracker Kata AWS Lambda 同款
OJ 在线判题 / 编程竞赛 Isolate nsjail IOI 官方，资源计量精细
CI 临时构建环境 Firecracker Docker / Podman 用完即毁
打包分发 Linux 桌面应用 Flatpak Snap 社区治理、冷启动快、Portal 细粒度
服务器/IoT 自动更新分发 Snap Flatpak Canonical 商店 + 自动更新
Windows 试装可疑软件 Windows Sandbox Sandboxie-Plus 真 VM，关闭即毁
Windows 长期隔离常用软件 Sandboxie-Plus — 多沙箱并存、细粒度
Windows 防勒索 / 系统还原 Shadow Defender — 注意：不防数据外泄
macOS 限制 CLI 工具权限 sandbox-exec（已废弃但可用） 微 VM（未来方向） 无官方替代

4.4 AI Agent 四层信任分级隔离策略

信任等级 场景举例 方案 理由
高（自己写的脚本、知名开源工具） 个人 dotfiles、ripgrep、fd 直接运行 无需开销
中（常规第三方包/npm/pip 依赖） npm install 未知依赖 Podman rootless 或 Distrobox 保护家目录，成本极低
低（AI 生成的一次性脚本） Claude/Codex/OpenCode 生成的脚本 Firejail + 自定义 profile 或 nsjail 限制文件读写 + 网络，瞬时启动
极低（来源完全未知的恶意代码） 网上下载的 exploit、来历不明二进制 gVisor / Kata / Firecracker 独立内核，无逃逸风险

4.5 关键差异极简总结

  1. Docker / Podman（容器）：运行完整应用环境，隔离偏重文件系统、网络。
  2. Firejail / bwrap（沙箱）：限制程序权限——禁止读写敏感目录、禁止系统调用，轻量化。
  3. Firecracker / Kata（微 VM / 安全容器）：介于容器和虚拟机之间，最强隔离，独立内核。
  4. gVisor：用用户态内核拦截系统调用，无需硬件虚拟化即可达到”非共享内核”效果。

本文由AI辅助整理而成。

  • 标题: 容器与沙箱知识文档
  • 作者: 简约无双
  • 创建于 : 2026-08-31 11:47:00
  • 更新于 : 2026-09-12 23:34:42
  • 链接: https://blog.jianyuewushuang.top/2026/08/31/容器与沙箱知识文档/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论
目录
容器与沙箱知识文档
  1. 一、基础概念与共同地基
    1. 1.1 容器 vs 沙箱：边界在哪里
    2. 1.2 隔离强度的五层谱系
    3. 1.3 共同地基：Linux 内核隔离
  2. 二、容器方案
    1. 2.1 Docker
    2. 2.2 Podman
    3. 2.3 containerd
    4. 2.4 CRI-O
    5. 2.5 nerdctl
    6. 2.6 runc / youki（OCI 低层运行时）
    7. 2.7 LXC（Linux Containers）
    8. 2.8 LXD / Incus（系统容器管理工具）
    9. 2.9 systemd-nspawn
    10. 2.10 Distrobox
    11. 2.11 Toolbx（Fedora）
    12. 2.12 Devbox
  3. 三、沙箱方案
    1. 3.1 Firejail
    2. 3.2 Bubblewrap (bwrap)
    3. 3.3 Flatpak
    4. 3.4 Snap
    5. 3.5 AppImage
    6. 3.6 nsjail
    7. 3.7 Isolate
    8. 3.8 Firecracker
    9. 3.9 gVisor（Google）
    10. 3.10 Kata Containers
    11. 3.11 Windows Sandbox
    12. 3.12 Sandboxie-Plus
    13. 3.13 Shadow Defender
    14. 3.14 macOS App Sandbox
    15. 3.15 sandbox-exec（Seatbelt 命令行）
  4. 四、横向对比与总结
    1. 4.1 全景对比总表
    2. 4.2 分层总览
    3. 4.3 场景化选型决策表
    4. 4.4 AI Agent 四层信任分级隔离策略
    5. 4.5 关键差异极简总结