Hacker News Reader

Comment by akazantsev | Hacker News Reader

That's because sandboxing is quite hard. I use `cco`, but even then, the home folder is exposed. You are one prompt away from the agent sending the browser passwords with curl.

To prevent this, you need a fake home and a networking whitelist for the agent to access the provider (llama cpp, OpenAI, etc.)

There is no cross-platform solution that is easy to use for this. And no, a Linux box with Docker won't do. I develop a cross-platform native app and want the agent to compile and fix the platform-specific errors.

View on HN

Sandboxing is a VERY HARD problem. I've been working on it for months, and finally have something that's mostly there:

- Sandbox on Linux using Docker, Podman, containerd, gVisor, Kata, Firecracker

- Sandbox on Mac using Docker (Docker Desktop or Orbstack), Podman, Apple containers, Seatbelt, Tart (Tart lets you run simulators).

- Network control

- Secrets control (file mounts or credentials broker)

- NO ambient data (ENV is replaced with a minimal and local-to-sandbox one)

- NO access to your homedir. You have to explicitly mount things you want.

- NO direct access to your workdir: Your work dir is never modified until you apply the changes, either standalone or as a git commit. You can also diff before applying. Git runs sandbox side in case the repo has filters.

- gitignored files never get copied in. The agent never sees them.

- Has built-in support for claude, codex, gemini, aider, and opencode, but you can also launch it in "shell" mode and run whatever you want.

- Supports VS code tunnels, so you can remotely access in VS code if you don't want to use the terminal.

- Full lifecycle support: Launch, attach, stop, restart, wait, one-shot, clone, destroy

- MCP passthrough

- Layered API (golang) if you want to sandbox other things

- Self-contained binary. No external requirements other than the backends you want to use. Defaults to a ~/.yoloai dir for config/data, but you can point it anywhere.

- FOSS

https://github.com/kstenerud/yoloai

i have a photon os vmware, agent has root and docker plus a few api keys with minimal credits.

if it messes up: - no sensitive data is there, so it doesn't really work for serious dev but it's secure for play time

- roll back and fix is done in 10s with ram snapshot

- dollar loss is $10 when it leaks the api key

but this seems quite overkill no?

I currently run pi agent in Lima on a Mac with only the code project folder mounted and an extension that prevents pi agent from reading the contents of .env files directly.

Yeah, there probably are some freak situations where this isn't safe enough, but I don't really see any realistic ways this is going to end up badly. Am I overlooking some obvious security holes?

I designed it to provide a single interface to agent sandboxing, no matter how far up the security tower you want to go.

It eliminates the manual process steps you end up doing with an ad-hoc system (which gets old the 10th time you do it).

Common weak points:

- The agent can access your homedir.

- The agent can access .gitignored files, which can contain secrets (and are gitignored for this reason).

- The agent has r/w access to your workdir.

- The agent could follow your remote mounted dirs.

- The agent can act in your name with whatever credentials it finds (and it will use them when it tries to be helpful, especially with the gh tool).

- Do you even know what's in the diagnose_problem.sh file it just created and asked permission to run?

- Even the .git dir can be weaponized, such as with evil filters.

- The agent can edit its own process, bypassing the harness controls and giving it the same access as you have (amplified by each credential sitting on that machine).

Meanwhile, you're reflex-hitting ENTER without looking because 99% of the permission prompts are mundane.

And that's before you even get to all of the idiosyncrasies in the backends that will eventually trip you up. The list is quite large and continually growing: https://github.com/kstenerud/yoloai/blob/main/docs/contribut...

Sandboxing in a container in Linux isn't hard, if you use lxd/incus which ships with Ubuntu/Debian.

It all seems so simple at first. Just launch a container/vm with a base image of your dev environment, mount whatever you need, do your work, and then tear down. Maybe add some iptables rules for good measure. Easy peasy, something any moderately competent dev could do and even put in a quick shell script.

I started with that assumption, but there are a lot more gotchas and security issues than you'd think.

This is exactly what VMs are for.

Heh, good luck with that.

Explain Mr vague.

I've already explained in some sister comments. Sandboxing is one of those things that seems very simple on the surface, and is EXTREMELY complicated once you start actually digging into the implications, gotchas, and security issues. The underlying tools were never designed with this use case in mind, so they need a little help to reach that last mile. And this glue is where all the chaos ensues.

Here's a small sample of the crazy shit you have to deal with: https://github.com/kstenerud/yoloai/blob/main/docs/contribut...

And that's if you're actually following the proper procedures (which are themselves byzantine and tricky to get right).

I use sandbox-here for this reason, it's a wrapper around bubblewrap, which works quite well.

Copy the code and adjust it to your liking:

https://github.com/lionkor/sbh

I have a shell alias for it, and use it like

    sbh --net pi

for example or

    sbh --net codex

and maybe add --docker if I expect it to do docker things.

This kind of wrapper is much easier to handle and maintain than a completely separate tool for sandboxing agents.

> That's because sandboxing is quite hard

colima makes it pretty easy, on macOS and linux at any rate.

https://colima.run

Still wild to name a sandboxing software after one of the most infamous Soviet Gulags in history.

It's wilder to accuse someone of naming the container version of the lima sandboxing software after a gulag.

These type of moral outrage comments take an extreme amount of effort to debunk compared to writing them.

1. There is no gulag called Colima, it doesn't exist.

2. There was a gulag near a river called Kolyma

3. The pronounciation and spelling of Kolyma and Colima are completely different, in fact Colima is an Aztec word

Colima stands for Containers on Lima. Lima stands for Linux Machines (a popular open-source utility used to launch Linux virtual machines on macOS).

> in fact Colima is an Aztec word

I was curious if the adjacent tool name (Lima) had anything to do with the capital of Peru, but I guess not.

Isn't it named after the Mexican state?

Others have covered why that isn't what's being done, but also if it was that would be a _fabulous_ joke.

I’m kind of sad it’s not named after it now, that would’ve been very amusing

Colima is in Mexico.

Kolyma is in Russia.

Use multipass by canonical. Works on macOS, windows, Linux.

If you work on Windows you most likely need Windows as VM

Using VMs to isolate LLM agents isn't hard at all. It is IMHO the only sane option.

Reply on news.ycombinator.com