Software sandboxing: The basics (2025)

Posted by mococa 19 hours ago

Comments

Comment by 10000truths 16 hours ago

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.

Comment by nine_k 12 hours ago

Fundamentally, Unix security is per user (in uid sense), identity-based with ambient authority, not capability-based with directly passed authority. There are many attempts to nerf, limit, lock down authority at the process level, but they all go against the initial architectural grain. Unix was not designed to protect users from themselves, only from each other.

Comment by mitxela 4 hours ago

People have tried to build the opposite. It doesn't work well. Except in very limited cases you always end up passing every privilege or a god privilege to make it practical.

Comment by int0x29 8 hours ago

By default when creating a new thread or process under Fuchsia you don't have access to the kernel. You have to create the thread or process with explicit kernel access. Pity Fuchsia kinda got killed off (Ok its not completely dead yet but its slowed a lot. There still doesn't seem to be a 2026 roadmap either)

Comment by Levitating 2 hours ago

Are there any operating systems that work like this?

Comment by brynet 15 hours ago

> At that time, its researchers have modified Chromium to make use of Capsicum and compared how much effort was required to make use of each sandboxing mechanism within Chromium. [..] If you’re only going to study one sandboxing mechanism in your life, it should be Capsicum. To this date, I have yet to see a better sandboxing mechanism than Capsicum.

In the years since it was added, there's a reason you can count on two hands the number of programs using it in FreeBSD. Even less using it effectively, with refactoring, and not just calling cap_enter().

Capsicum Chrome has never been committed to the official FreeBSD ports tree, it was an academic research project from 17 years ago.

https://github.com/rwatson/chromium-capsicum

https://www.freshports.org/www/chromium/

https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=...

No browsers on FreeBSD today use Capsicum.

Compare that instead to OpenBSD, where the Chromium port has used pledge(2) since January 2016, and unveil(2) since 2018. Enabled by default. The Mozilla Firefox ports also use both pledge and unveil since 2018-2019, and this work has even been accepted upstream.

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...

Comment by shiomiru 5 hours ago

> No browsers on FreeBSD today use Capsicum.

Strictly speaking, that's false, my hobby project chawan[1] supports capsicum :)

Anyway, IME capsicum vs pledge doesn't make much of a difference because seccomp already forces you into a specific sandbox architecture; after implementing that, adjusting the result to support the rest takes (relatively) little effort. So I think the difference in adoption is more because nobody has volunteered to do the work for capsicum (and keep it up to date etc.)

[1]: https://chawan.net

Comment by sieve 16 hours ago

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.

Comment by JonChesterfield 15 hours ago

Highly recommend qemu instead. The sandbox machines are just more IP addresses on the local network. If you want them completely offline, put them on a network that doesn't have a route to anywhere. The sketchy AI harness is very happy with a whole machine to itself, complete with root access. You can push/pull git repos in from the outside, so all it can do is trash it's own sandbox and get reinstated from scratch by the physical machine below it.

Comment by wmf 12 hours ago

VM tech has improved since then. Today you'd probably want to use Firecracker or Cloud Hypervisor with virtio-vsock instead of networking.

Comment by LoganDark 10 hours ago

Surprised to see no mention of Qubes OS yet. It's somewhat like the QEMU approach but with a type 1 hypervisor (Xen).

Comment by doc_ick 11 hours ago

Oh go ahead and damage random parts to your system if you want, just let the majority of non-tech or non-risk users benefit from some strong defaults.

Comment by Panino 16 hours ago

Justine Tunney wrote a port of OpenBSD pledge to Linux, in the form of a wrapper for seccomp-bpf.

https://archive.is/3FSWy

Not sure why her TLS cert expired months ago. Ted Unangst (OpenBSD dev) also seems to have disappeared, which is concerning.

Comment by 5 hours ago

Comment by jmclnx 17 hours ago

Interesting no mentioned about OpenBSD pledge(2), unveil(2). By far the easiest sandboxing out there. An example:

    #ifdef OpenBSD
      if(pledge("stdio rpath wpath cpath",NULL) == -1)
        err(1,"pledge\n");
    #endif

Very easy, all the other examples seem rather complex to me. unveil(2) is just as easy.

Comment by mitxela 4 hours ago

Works because OpenBSD has totalitarian control of the ecosystem, just like Windows. Wouldn't work on Linux because what do those flags even mean to the kernel?

Comment by shiomiru 2 hours ago

This is often repeated in these kinds of threads, but I don't think it's true. You just have to implement it in glibc, which can map the flags to the actual syscalls used on the current architecture and restrict the process to those with a seccomp BPF filter.

(Indeed, cosmo libc does exactly that, so it's definitely possible.)

Comment by aadyachinubhai 14 hours ago

For LLM generated Python code, pydantic's monty is awesome: https://github.com/pydantic/monty

Plus, pydantic is funded so it will be well maintained.

Comment by falaki 9 hours ago

A must read for OpenAI engineers.

Comment by DubiousPusher 15 hours ago

I hand rolled a sandbox with credential injections on call out using WSL and mitm and Windows credential manager. The only credential I had to have in the box was a fine grained PAT with copilot response. I used some hacky git push/pull to move work in and out of the sandbox. For collaborative UX review I would switch the agent to limited perms and CDP back to my host browser.

Recently I moved to Docker Sandboxes. This removed most of what I was having to hand roll. Though I still own the renewal for short lived tokens. The git setup in docker sandbox is especially nice. The host is served as a remote 'host' in the sandbox and it can read but not write the host's origin.

On the host, each sandbox got is reachable as sandbox-[name].

https://www.docker.com/products/docker-sandboxes/

Comment by coder-pm 5 hours ago

Nice setup, I'm curious about the PAT. Even fine-grained permissions are working till the expiration so if the box will die someone has it for the whole time. Did you rotate it per session or it was on default expiration time?