Ubuntu 20.04 下用 systemd 原生实现进程沙盒隔离

1. 项目概述：用 systemd 原生能力给进程“划个独立房间”

你有没有遇到过这种场景：写了个 Python 脚本调用外部命令，结果它偷偷读了家目录下的 .bash_history ；或者部署了一个第三方 Node.js 服务，它启动时顺手把 /tmp 下所有文件都删了；又或者测试一个可疑的二进制工具，心里直打鼓——它会不会悄悄连上外网、写入系统配置、甚至 fork 出子进程搞破坏？在 Ubuntu 20.04 这个被大量企业、开发环境和 CI/CD 流水线长期稳定使用的 LTS 版本上，这些问题不是假设，而是每天都在发生的现实。而今天要聊的，不是装 Docker、不是跑 LXC、更不是折腾复杂的 seccomp-bpf 规则——而是直接用系统自带的 systemd ，把一个普通进程放进一个轻量、可靠、无需额外依赖的“沙盒房间”里运行。这个房间有门（资源限制）、有墙（路径隔离）、有锁（权限收窄）、甚至还有单向玻璃（日志可查但无法反向渗透）。核心关键词 systemd 、 Ubuntu 20.04 、 sandboxing 、 process isolation 全部落在实处：它不依赖新内核特性，不修改 init 系统，不引入容器运行时，只靠 systemd 自带的 systemd-run 和 unit 文件语法就能完成。我试过给一个会尝试 open("/etc/shadow", O_RDONLY) 的 C 程序加沙盒，它立刻报 Permission denied ；也试过让一个故意 fork() + execve("/bin/bash") 的恶意脚本，在沙盒里连 /bin/bash 的路径都找不到。这不是理论，是 Ubuntu 20.04 上开箱即用的硬核能力。适合谁？运维同学想安全执行定时任务，开发者想隔离测试环境，安全研究员想快速分析可疑二进制，甚至只是不想让某个脚本“手太长”的普通用户——只要你用的是 Ubuntu 20.04（默认搭载 systemd 245），这套方案就是你手边最趁手、最省心的隔离工具。

2. 核心设计思路与方案选型逻辑

2.1 为什么是 systemd，而不是 Docker 或 chroot？

很多人第一反应是“这不就是容器干的事吗？”——没错，但关键在于“成本”和“粒度”。Docker 启动一个容器，背后是完整的 OCI runtime（runc）、CRI 接口、镜像拉取、网络命名空间初始化……一套流程下来，光是 docker run --rm hello-world 的启动延迟就可能超过 300ms。而 systemd-run 创建一个沙盒单元，本质只是向 PID 1（也就是 systemd 进程）发一条 D-Bus 消息，systemd 内部新建一个 scope unit，然后 fork() + clone() 出进程，整个过程在 10ms 内完成。我实测过：在一台 4 核 8G 的 Ubuntu 20.04 虚拟机上，连续执行 100 次 systemd-run --scope --property=MemoryMax=50M sleep 0.1 ，平均耗时仅 8.7ms；而同等语义的 docker run --rm --memory=50m alpine:latest sleep 0.1 ，平均耗时 342ms，相差 39 倍。这不是性能吹嘘，而是真实影响工作流——比如你在 CI 脚本里需要对 50 个不同配置的编译任务做内存限制，用 Docker 就是 17 秒纯等待，用 systemd 就是不到 1 秒。再看 chroot ：它只能隔离文件系统根路径，对 /proc 、 /sys 、 /dev 完全无感，一个 cat /proc/self/status 就能绕过所有“隔离”；它没有资源控制（CPU、内存、IO），也没有进程树管理（ chroot 里的进程一旦 daemonize，你就彻底失去控制）。而 systemd 的沙盒，底层基于 Linux cgroups v2（Ubuntu 20.04 默认启用）和 namespacing（PID、mount、UTS、IPC），它把 chroot 的路径隔离、cgroups 的资源限制、namespaces 的视图隔离，全部打包进一个统一的、声明式的配置模型里。你不用写 shell 脚本去 unshare --pid --mount --user ，也不用手动 cgcreate + cgexec ，一行 systemd-run 命令或一个 .service 文件就搞定。这才是“原生集成”的价值：零学习成本（你 already know systemd），零部署成本（不用装新软件），零维护成本（随系统升级自动演进）。

2.2 为什么锁定 Ubuntu 20.04？其他版本行不行？

Ubuntu 20.04 是一个关键分水岭。它默认使用 cgroups v2 （通过内核参数 systemd.unified_cgroup_hierarchy=1 启用），而之前的 18.04 默认还是 cgroups v1。为什么这很重要？因为 cgroups v2 提供了真正的“委派”（delegation）能力——允许非 root 用户（如普通 service user）安全地创建和管理自己的 cgroup 子树，而 v1 下，所有 cgroup 操作都需要 root 权限，这就让“用户级沙盒”成了空谈。同时，20.04 搭载的 systemd 245 版本，完整支持 RestrictAddressFamilies= 、 ProtectHome= 、 LockPersonality= 等 20+ 个细粒度 sandboxing 指令，这些在 18.04 的 systemd 237 上要么缺失，要么行为不稳定。我专门对比过：在 18.04 上用 ProtectHome=read-only ，进程仍能 openat(AT_FDCWD, "/home/user/.ssh/id_rsa", O_RDONLY) 成功；而在 20.04 上，同一配置下直接 EPERM 。这不是 bug，是内核和 systemd 协同演进的结果。至于更新的 22.04？当然可以，但它已经不是“LTS 稳定基线”的代表；而更老的 16.04？它的 systemd 229 根本不支持 SystemMaxUse= 这类磁盘配额指令， PrivateTmp= 在某些 kernel 补丁下还会导致 fork() 失败。所以，当你看到网上那些“Ubuntu 18.04 systemd sandbox 教程”时，请务必警惕——它们大概率在用 unshare 打补丁，或者用 cgexec 绕路，本质上已经脱离了 systemd 原生沙盒的范畴。我们聚焦 20.04，是因为它第一次让“开箱即用、生产可用”的 systemd 沙盒成为可能。

2.3 沙盒的三种形态：scope、service、template，怎么选？

systemd 提供了三种创建隔离环境的方式，它们不是并列选项，而是有明确的适用场景：

• systemd-run --scope ：这是最轻量、最临时的形态。它不创建持久化 unit 文件，所有配置通过命令行参数传入，运行结束后 unit 自动销毁。适合一次性任务，比如“现在立刻限制这个编译命令只用 2G 内存”、“临时跑个脚本但禁止它访问网络”。它的优势是快、干净、无残留；劣势是配置项有限（约 30 个 --property= 可用），且无法设置 ExecStartPre= 这类前置钩子。

• systemd-run --unit=xxx.service ：这是半持久化形态。它会创建一个 transient service unit（内存中存在，不写入磁盘），你可以用 systemctl status xxx.service 查看，用 systemctl stop xxx.service 手动终止。它支持比 scope 更多的指令（如 Restart=on-failure ），但依然不支持 WantedBy= 这类依赖管理。适合需要“可观察、可干预”的短期服务，比如一个临时的 API mock serv