软件沙箱化：从原理到实践
Software Sandboxing: The Basics
探索软件沙箱化的核心概念，从程序化权限降级到无 root 权限的权限剥离，再到自由裁量权限降级。文章深入分析了 Linux namespaces 的局限性与 Landlock 等新机制的潜力，并结合 Emilua 的实际开发经验，展示了如何通过 Actor 模型和基于能力的架构实现高效的沙箱化。通过实例代码和理论探讨，帮助开发者理解如何在现代操作系统中构建安全的沙箱环境。
沙箱化并不意味着完全取代系统管理策略，而是与之相辅相成，共同构建更安全的软件环境。
HN 评论区
13- 10000truths
需要降权的根本原因，是进程创建 API 默认采用“继承所有能力”的语义。如果你不要求兼容现有软件，绝不会用这种方式去构建新的虚拟机或操作系统。安全的方案始终是“默认无权限”语义，即通过进程创建 API 中的显式参数授予白名单能力。
在 Linux 上，最接近这种模型的是 seccomp 的严格模式（strict mode），它禁止除 read()、write()、exit() 和 sigreturn() 之外的所有系统调用。这基本上是将进程限制为仅具备“纯计算/内存”能力。如果该进程随后想要与外部世界交互，只能通过读写它在调用 seccomp 之前继承的文件描述符来实现。你可以基于此构建 RPC 来模拟“白名单”，而访问控制和限制/策略则由另一端监听的服务强制执行。
- brynet
>
> 当时，研究人员修改了 Chromium 以使用 Capsicum，并比较了在 Chromium 中使用每种沙箱机制所需的工作量。[..] 如果你一生中只研究一种沙箱机制，那应该是 Capsicum。迄今为止，我尚未见过比 Capsicum 更好的沙箱机制。
自 Capsicum 加入 FreeBSD 以来的这些年里，能用手指数得清的使用它的程序数量是有原因的。真正有效使用它（包含重构，而不仅仅是调用 cap_enter()）的程序更是寥寥无几。
Capsicum 版的 Chrome 从未被提交到官方的 FreeBSD ports tree，那只是 17 年前的一项学术研究项目。
https://github.com/rwatson/chromium-capsicum
https://www.freshports.org/www/chromium/
https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=...
如今 FreeBSD 上没有任何浏览器使用 Capsicum。
相比之下，看看 OpenBSD：其 Chromium port 自 2016 年 1 月起就已使用 pledge(2)，自 2018 年起使用 unveil(2)，且默认开启。Mozilla Firefox 的 ports 自 2018-2019 年也同时使用了 pledge 和 unveil，这项工作甚至已被上游接纳。
https://marc.info/?l=openbsd-ports-cvs&m=145211683609002&w=2
https://github.com/openbsd/ports/blob/master/www/chromium/pa...
https://github.com/openbsd/ports/tree/master/www/chromium/fi...