在生产环境中使用 Linux namespace 与 seccomp 构建沙箱时，核心挑战不在于理解隔离机制本身，而在于将抽象的隔离能力转化为可量化、可监控、可回滚的工程参数。本文从文件系统权限控制、网络流量过滤、系统调用白名单三个维度，给出可直接落地的配置建议与避坑指南。

文件系统隔离的工程参数

文件系统隔离是沙箱安全的第一道防线。Linux namespace 中的 mount namespace 允许进程拥有独立的文件系统视图，但这并不意味着可以随意挂载。工程实现时需要关注三个核心参数：挂载点绑定范围、只读标记、以及 /proc 与 /sys 的处理方式。

在基于 Bubblewrap 的实现中，默认行为是创建一个全新的文件系统视图，宿主机的根目录默认不可见。但对于需要访问特定目录的场景，推荐使用 --bind 参数显式绑定，并始终在绑定时加上 :ro 只读标记，除非业务明确要求写权限。一个可落地的经验法则是：写权限仅授予 /tmp 的子目录或应用专属的输出目录，且目录所有者应为非 root 用户（UID ≥ 10000）。如果业务需要读取配置文件，优先使用 --bind /etc/myapp:ro 而非开放整个 /etc 目录。

/proc 和 /sys 的处理尤为关键。在沙箱内部，/proc 需要以只读方式挂载或使用 proc 类型挂载（不传递任何额外参数时 Bubblewrap 会自动处理），但绝对不能将宿主机的 /proc 直接绑定进去，否则进程可能通过 /proc/self/environ 等路径窃取敏感环境变量。网络命名空间启用时，/sys/class/net 等路径的可见性也需要关注，建议通过 unshare --net 隔离网络后手动挂载必要的虚拟文件系统，而非直接暴露宿主机的 /sys。

网络过滤的实践方案

网络隔离在 Linux namespace 中通过创建独立的 network namespace 实现，默认情况下沙箱进程无法访问外部网络。如果业务需要有限的网络访问，Bubblewrap 提供了 --network 参数来启用网络，但更细粒度的域名级控制需要结合 iptables 或 nftables 实现白名单机制。

一个实用的工程配置是：默认禁止所有出站流量，仅对业务明确需要的域名开放 443 端口。具体实现可以通过 --allow-net=api.example.com 参数传递到沙箱启动器，内部通过本地 DNS 解析或 hosts 文件注入将域名限定在预设列表内。对于需要调用多个外部服务的场景，建议在沙箱配置中采用服务分类策略：允许列表（allow-list）之外的域名默认拒绝，并通过环境变量 HTTPS_PROXY 强制所有 HTTP/HTTPS 流量经过本地代理以便日志记录与调试。

网络代理层面的 Secrets 注入是一个容易被忽视的工程点。Zerobox 等工具通过替换环境变量占位符的方式实现敏感信息保护，原理是沙箱内部的进程看到的是类似 ZEROBOX_SECRET_xxx 的占位符，只有当流量命中预设的域名白名单时，代理层才会将占位符替换为真实密钥。这一机制需要业务侧配合：若沙箱内运行的是 Node.js 应用，需要显式传入 --use-env-proxy 参数以确保 fetch API 走系统代理，否则凭证替换机制会失效。

Seccomp 系统调用过滤的配置阈值

Seccomp-bpf 是沙箱的最后一道防线，通过过滤系统调用来限制进程的能力边界。与文件系统策略不同，系统调用策略的制定需要更精细的迭代过程。工程实践中推荐采用三阶段策略：初始阶段使用日志模式（SCMP_ACT_LOG）记录所有被拦截的系统调用，中期阶段根据日志逐步放宽白名单，交付阶段切换为强制模式（SCMP_ACT_KILL 或 SCMP_ACT_ERRNO）。

一个最小化但不阻塞主流应用的系统调用白名单通常包含以下类别：文件操作类（read、write、openat、close、fstat、lseek、mprotect、mmap）、进程管理类（exit、exit_group、brk、rt_sigprocmask）、时间类（clock_gettime、gettimeofday、nanosleep）、网络类（socket、connect、accept、recvfrom、sendto，仅在启用网络时）。实际配置时可以使用 libseccomp 提供的 scmp_filter_ctx 接口构建白名单，或者直接引用社区维护的通用策略如 Chromium 的 seccomp-bpf 配置文件作为起点。

需要特别注意两点：一是 32 位与 64 位系统调用的区分，在 x86-64 系统上运行 32 位程序时需要同时添加对应的 compat 系统调用号；二是 execve 的处理 —— 如果沙箱需要执行子进程，必须在白名单中加入 execve 或 execveat，同时做好子进程同样受沙箱策略约束的心理准备，这意味着在沙箱内部启动的进程将继承父进程的所有限制。

资源限制与可观测性

除了隔离机制，资源限制与可观测性是生产环境沙箱不可或缺的补充层。通过 cgroup 可以限制沙箱进程的 CPU 与内存使用，常见的配置阈值是将内存上限设为宿主机可用内存的 1/4 到 1/2，CPU 份额设为 1024（对应单核的满载权重）。对于短时任务型沙箱，可额外设置 pids cgroup 限制以防止 fork 炸弹攻击。

可观测性方面的最佳实践是在沙箱启动时启用调试模式，记录配置决策与关键事件。Zerobox 提供了 --debug 参数将决策过程输出到 stderr，生产环境可以将其重定向到日志收集系统。当系统调用被拦截时，日志中应包含被拦截的系统调用号、进程 PID、以及触发时的调用栈信息，这些数据是后续调整白名单的核心依据。

回滚与故障恢复

任何沙箱策略都有可能产生误拦截导致业务中断，因此必须预设回滚机制。最简单的方式是通过环境变量或配置文件维护两套策略 —— 默认策略（宽松）与生产策略（严格），在发现大规模异常时可在数秒内切换回默认策略。在 CI/CD 流水线中，建议将沙箱测试作为独立的 stage 先行运行，验证系统调用白名单与文件访问权限是否满足业务需求后再进入部署环节。

综合来看，基于 Linux namespace 与 seccomp 的沙箱工程实现并非一次性配置，而是围绕文件访问、网络边界、系统调用三个维度持续迭代的过程。从最小权限原则出发，以日志驱动调优，最终在安全与可用性之间找到适合业务实际的平衡点。

参考资料