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.
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.
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...
#ifdef OpenBSD
if(pledge("stdio rpath wpath cpath",NULL) == -1)
err(1,"pledge\n");
#endif
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].
Not sure why her TLS cert expired months ago. Ted Unangst (OpenBSD dev) also seems to have disappeared, which is concerning.
[deleted]
Plus, pydantic is funded so it will be well maintained.
[dead]
[dead]
[dead]
[dead]
[deleted]
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.
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
(Indeed, cosmo libc does exactly that, so it's definitely possible.)