Software Sandboxing Is Still Uncharted Territory, and Linux Namespaces Are a Bad Bet
Software Sandboxing: The Basics
Drawing on experience building sandboxing for Emilua, this post argues that proper sandboxing means discretionary privilege dropping—restricting a process without admin rights. Traditional UNIX tools fall short, and Linux namespaces, popularized by Docker, dangerously expand the kernel attack surface. The author recommends the actor model and capability-based security, showing how three functions in Emilua enable compartmentalized, message-passing applications.
I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN over any network namespace and to thus access the network configuration API to be a huge risk. For example, unprivileged users can program iptables. I'll eat my hat if there are no privilege escalations in there.
- 10000truths
The need to drop privileges at all is a natural consequence of a process spawning API with inherit-by-default capability semantics. You'd never build a new VM or OS this way if you didn't require compatibility with existing software. The secure solution has always been default-nothing semantics, with whitelisted capabilities granted via explicit arguments in the process spawning API.
The closest you can get to that model on Linux is the strict mode in seccomp, which disallows every syscall except read(), write(), exit() and sigreturn(). It's more or less a way to restrict a process to being "pure compute/memory". If the process then wants to poke and prod at the outside world, it can only do so by reading/writing the file descriptors it inherited prior to the seccomp call. You can build a RPC on top of that to emulate the "whitelist", with access control and restrictions/policies enforced by whatever is listening on the other end.
- sieve
I became interested in sandboxing last month after watching LLMs fail to respect basic boundaries. Well, the very expectation that they would is foolish in the first place.
I am not a fan of application-level sandboxing. The JVM tried with its security manager, and Deno with its allow/deny, but it is not general enough for me. At some point you have to assume that anything you run on your machine is possibly broken/compromised and then deal with the situation depending on your risk appetite.
This is a long story that I have written about on my blog, but I decided to go down the Bubblewrap + seccomp + socat route for the sandboxing tool I built. Let's me run harnesses and compilers and even headless Firefox in sandboxes without worrying about damage to random parts of my system.