Rendered at 11:28:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
10000truths 14 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.
nine_k 9 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.
mitxela 2 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.
int0x29 5 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)
brynet 13 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.
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.)
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.
JonChesterfield 12 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.
wmf 9 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.
LoganDark 8 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).
doc_ick 9 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.
2 hours ago [-]
Panino 13 hours ago [-]
Justine Tunney wrote a port of OpenBSD pledge to Linux, in the form of a wrapper for seccomp-bpf.
Very easy, all the other examples seem rather complex to me. unveil(2) is just as easy.
mitxela 2 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?
Plus, pydantic is funded so it will be well maintained.
falaki 7 hours ago [-]
A must read for OpenAI engineers.
DubiousPusher 13 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].
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 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.
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...
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
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.
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.
Plus, pydantic is funded so it will be well maintained.
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/