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.
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.
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)
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.
Sure, you can't avoid poorly designed apps. But a poorly designed app is much easier to fix/replace than a poorly designed OS, particularly when it comes to open-source software.
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.
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.
>At some point you have to assume that anything you run on your machine is possibly broken/compromised
You have to treat AI like has 'physical' access to where you are running it, Dev VM or laptop or in a browser. Anything connected to that which you or the context the AI is running under can access or exploit/abuse is at risk, almost as if an attacker had physical access.
It's like when I set was set up as a new SysAdmin with only view rights to Active Directory. I could not be trusted until proven otherwise (pass training) and I'm a human that can be held accountable.
> 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.
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.
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.)
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?
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.)
Er... nothing? That's the point, if you statically link to glibc 2.51, then you get a version of pledge where "stdio" allows the stdio syscalls made by glibc 2.51 (say, "read" and "write"). Next time if you link to glibc 2.52, you get a pledge that allows stdio syscalls made by 2.52 (maybe "pread" and "pwrite"), etc. Nothing changes for the user because the libc wrappers for "read"/"write" are synchronized with the pledge promises.
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].
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?
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.
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.
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)
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.
Sure, you can't avoid poorly designed apps. But a poorly designed app is much easier to fix/replace than a poorly designed OS, particularly when it comes to open-source software.
Are there any operating systems that work like this?
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.
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.
VM tech has improved since then. Today you'd probably want to use Firecracker or Cloud Hypervisor with virtio-vsock instead of networking.
Surprised to see no mention of Qubes OS yet. It's somewhat like the QEMU approach but with a type 1 hypervisor (Xen).
>At some point you have to assume that anything you run on your machine is possibly broken/compromised
You have to treat AI like has 'physical' access to where you are running it, Dev VM or laptop or in a browser. Anything connected to that which you or the context the AI is running under can access or exploit/abuse is at risk, almost as if an attacker had physical access.
It's like when I set was set up as a new SysAdmin with only view rights to Active Directory. I could not be trusted until proven otherwise (pass training) and I'm a human that can be held accountable.
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.
> 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...
> 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
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.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?
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.)
And then you run a program statically linked with a different version of glibc or musl and what happens?
Er... nothing? That's the point, if you statically link to glibc 2.51, then you get a version of pledge where "stdio" allows the stdio syscalls made by glibc 2.51 (say, "read" and "write"). Next time if you link to glibc 2.52, you get a pledge that allows stdio syscalls made by 2.52 (maybe "pread" and "pwrite"), etc. Nothing changes for the user because the libc wrappers for "read"/"write" are synchronized with the pledge promises.
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/
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?
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.
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.
A must read for OpenAI engineers.
[flagged]
[flagged]
[dead]
[dead]