Software sandboxing: The basics (2025)

For the simple reason that using Capsicum requires you to not only restructure your program (= by opening file descriptors ahead of time and using e.g. openat), but also by using FreeBSD specific functions provided by libcasper.

Basically with e.g. Landlock and unveil, you write maybe 10-20 lines and you're good to go. With Capsicum you have to fundamentally rewrite your entire program.

It also puzzles me. I'll try to answer below, but we'll never know the answer so my guess is as good as any.

For outsiders, BSD is a confusing ecosystem. You have FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. For outsiders, there's no criteria to favor one over the other, nor any criteria to adhere to some "official" flavor.

If Chrome (or Firefox) added support for Capsicum, it'd only support FreeBSD. Therefore there's no reason for a random maintainer (who's likely an BSD outsider) to accept such PRs (any accepted PR is code that the official team will have to maintain and check against CI, and so on...).

IMO fragmentation of basic APIs is only harmful to the whole BSD ecosystem. Basic APIs such as setresuid(), SOCK_SEQPACKET over AF_UNIX, and a lot more are evidence that there's no reason to offer the same functionality under a different API. There's no benefit to gratuitous fragmentation, and fortunately we already sorted many of the issues in the APIs I just mentioned, but there's still a lot of basic stuff that we can't do portably among different BSD systems. For instance, only recently we got memory file descriptors for NetBSD (they existed in FreeBSD for a long time already). If you want to use memory file descriptors on OpenBSD or DragonFly BSD, you have to do the boring loop to avoid name clashes on opening temporary files (and it'll never be as robust and clear as just creating a memory file descriptor).

Capsicum isn't as basic as memory file descriptors so it's gonna take longer, but sandboxing is a basic need on modern software development. We don't create sandboxes as frequently only because it's horrendously hard to do so. The APIs that systems provide nowadays are just awful. We do want to create sandboxes. That's why projects such as Tauri gain so much attention.

So Capsicum failed to conquer even the BSD ecosystem. Therefore it'll fail even harder to conquer the space outside BSD. Linux will never adopt it. BSD systems fail to agree with each other even on some basic things (again: only recently NetBSD added support for memfd_create).

Instead of implementing Linux APIs as BSDs are forced to do nowadays just to compile recent software, they could instead agree on just a few C APIs among themselves first, and then have a better chance at seeing them being adopted on Linux later so they don't need to just accept defeat over whatever Linux folks create, and actually contribute to the larger ecosystem.

I believe there's room to respect differences between the philosophies among the BSDs still, but creating incompatible APIs for the same purposes isn't helping anyone. They should innovate on new spaces, not on spaces where they already "lost" and one of the competing approaches already got the right answer.

DragonFly BSD has HAMMER. OpenBSD has httpd. FreeBSD has the MAC framework. All innovations on different spaces. They do not need to unify on that. They can go their separate ways on that. However why are each one reinventing the APIs for the same basic stuff? Kqueue was a complex API that everyone agreed it was the right approach and just adopted. Kqueue was a victory. Why can't they do the same for Capsicum already?

Capsicum may not have caught on, but capabilities are having a bit of a comeback right now. WASI, the wasm system interface, started with a classic UNIX-style API in 0.1 but now pivoted hard and is fully leaning into capabilities. And it makes sense there too, because wasm itself is fully free of ambient authority. You don't need any sandboxing because nothing is globally visible to begin with.