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.
> 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, 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.
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.
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.
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].
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.
> 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, 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...
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.
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.
Interesting no mentioned about OpenBSD pledge(2), unveil(2). By far the easiest sandboxing out there. An example:
Very easy, all the other examples seem rather complex to me. unveil(2) is just as easy.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/