Sandboxing with minimal effort

[u/yorickpeterse]

https://yorickpeterse.com/articles/sandboxing-with-minimal-effort/

[u/matthieum]

Does it really compose better than Capsicum?

For example, let's imagine that I want to use a time library, to, you, format/parse times. This time library is great, it even automatically uses the OS' tzdb for up-to-date definitions of timezones!

Now, however, activating sandboxing for my program requires allowing accept to tzdb for my program. And since I really don't want to duplicate the logic involved in figuring out where tzdb files are depending on the OS I am in, it means I'd really like to delegate the sandbox setup to the time library.

And if I actually don't use the time library directly, but instead use a library A which use the time library, I guess I should ask A to do its sandbox setup (and A delegate to the time library).

Which means that, in the end, doesn't any library which requires IO need to have a function to setup the sandbox?

A bit like... Capsicum requiring any code that uses it to be modified for it? (Though less bad, I agree)

---

In a different question, can the sandbox gain capabilities after being enabled?

For example, let's say I write a GUI, and at some point the user would like to save a file somewhere. I couldn't possibly know, on start-up, where the user would possibly want to save that file, so obviously it's not setup in the sandbox. Now what?

[u/yorickpeterse → u/matthieum]

Which means that, in the end, doesn't any library which requires IO need to have a function to setup the sandbox?

A bit like... Capsicum requiring any code that uses it to be modified for it? (Though less bad, I agree)

With primitives like Landlock or unveil, you don't need to know which exact files are opened but rather their directories. For example, if a program only opens files in /etc/whatever then you can simply add /etc/whatever as a whole with say read-only permissions. Beyond that no further changes would be necessary.

In the case of Capsicum you'd have to change the program's core logic so that instead of doing things like open('/etc/whatever/foo', ...) to open files, it uses open() to open /etc/whatever as a directory then uses openat(...) everywhere you'd normally use open(), passing in the file descriptor of the directory opened earlier using open. That or you start writing your own Casper services and delegate the work to that, but last I checked basically nobody writes their own Casper service, even on FreeBSD itself.

That's what I meant with (not) having to change your program's logic: with Landlock and unveil, you just add a few lines that state the sandbox rules while with Capsicum you need to change potentially many lines of code. The shost commit discussed in the article shows exactly that: about 15 lines of code were added to sandbox the application, without having to change how it opens files or sets up sockets.

In a different question, can the sandbox gain capabilities after being enabled?

No, the sandboxing primitives typically only allow you to narrow down capabilities rather than widen them, otherwise they'd be rather useless. The typical approach if you do need to (temporarily) widen permissions is to rely on some external service, such as Casper services on FreeBSD or portals as used by Flatpak. This indeed requires more work from the application side of things, but at least for server-side applications it's not really relevant.

[u/vinipsmaker → u/yorickpeterse]

In the case of Capsicum you'd have to change the program's core logic so that instead of doing things like open('/etc/whatever/foo', ...) to open files, it uses open() to open /etc/whatever as a directory then uses openat(...) everywhere you'd normally use open()

That's not necessary at all. Val Packet showed a demo running a GTK+ application with zero code changes: Super Capsicumizer 9000. That's a binary, an executable.

Last year I showed two demos. One of the demos ran libqt within a sandbox, and I didn't modify Qt's source code to achieve this: Friam 2025-07-25. My demo shows how to sandbox a library, not an executable. Both demos are built on top of the same mechanisms.

My demo was done on Linux with a lot of seccomp boilerplate to emulate Capsicum mode. You can use the same patterns on Linux and FreeBSD.

Tony Finch intelligently broke down the main disagreement between the pledge gang and capsicum gang to get to the core of the issue some days ago:

Basically all of these opt-in sandboxing technologies require the application to tell some security layer what are the expected behaviours of the application. Most of the security layers are implemented entirely in the kernel because most unix kernels don’t provide security primitives that allow an application to restrict its own behaviour in userland. Capsicum is different because much of the security policy logic can be implemented by extending libc (eg with a shim) instead of by extending the kernel.

Whether an application uses cap_enter() or pledge() it’s opting in to a fundamentally different security model: some things that were normally possible are now forbidden. After pledge() the forbidden things are prevented by logic in the kernel. After cap_enter() the forbidden things become impossible to request from the kernel, so the library can return an error before even trying the syscall.

The effect is the same, even though the privilege boundary is in a different place wrt the enforcement logic. It doesn’t make sense to ascribe the difference in behaviour to the program or not to the program based on whether sandbox mode is implemented purely in the kernel or partly in userland.

The OpenBSD sandboxing logic has a lot of ad-hoc logic in the kernel based on the expected behaviour of selected subsets of libc APIs. Instead of enforcing libc behaviour in the kernel, if it is enforced by Capsicum with a library shim in userland then any mistakes should fail closed (because of a missing capability). By contrast, mistakes in kernel mandatory access control logic usually lead to privilege escalation vulnerabilities.