3 ms·

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

by sieve 15d 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.

JonChesterfield 14d 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 14d 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 14d 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 14d 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.
selicos 14d ago
>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.

by sieve 15d ago

JonChesterfield 14d 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 14d 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 14d 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 14d 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.

selicos 14d ago

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