saved
Software sandboxing: The basics
Hraness cites a source capture. The source author remains the source.
gist
The Emilua author's long field guide defines software sandboxing as discretionary privilege dropping a process can do programmatically without admin rights. Privilege boundaries sit at process credentials and ambient authority; FreeBSD Capsicum's one-call cap_enter is the model, while Linux namespaces expand kernel attack surface and should stay for containers. For Linux, Seccomp plus Landlock is the workable pair. Actor messaging over UNIX domain sockets with capability-style file descriptors is the recommended compartmentalization pattern, with libc interposition for legacy code.
ideas
- Sandbox means discretionary privilege dropping. Restrict a process programmatically, without administrative authority, by dropping ambient rights rather than raising them via suid helpers.
- Namespaces are for containers, not sandboxes. Nested user namespaces expose CAP_NET_ADMIN-class kernel paths to every user; Landlock and newer restrictors avoid that explosion.
- Capsicum is the teaching model. cap_enter disables ambient authority so only already-held file descriptors work; Chromium needed ~100 LOC with Capsicum versus thousands for seccomp.
- Actors plus capabilities compartmentalize. Processes as actors message over UNIX domain sockets, send FDs as unforgeable rights, and prove no sandboxed actor holds forbidden combinations.
- Linux reality is Seccomp + Landlock. Seccomp blacklists rot across arches and new syscalls; Landlock filters the filesystem while you still fight /proc and multiarch numbering.
quotes
“Privileges should only ever decrease, never increase (principle of least privilege).”
“Linux namespaces is a terrible interface for software sandboxing.”
“If you’re only going to study one sandboxing mechanism in your life, it should be Capsicum.”
“For Linux, Seccomp + Landlock is what we have.”