Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Zerobox – Sandbox any command with file, network, credential controls

github.com

Post reply on HN
Print view View original

31–40 of 108 posts

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#31

Post by afshinmeh »

simonw wrote: post #26
afshinmeh wrote: post #22

Earlier quoted context omitted.

Thanks and agreed! Zerobox uses the Deno sandboxing policy and also the same pattern for cred injection (placeholders as env vars, replaced at network call time). Real secrets are never readable by any processes inside the sandbox: ``` zerobox -- echo $OPENAI_API_KEY ZEROBOX_SECRET_a1b2c3d4e5... ```

Do you know if there's a widely shared name for this pattern? I've been collecting examples of it recently - it's a really good idea - but I'm not sure if there's good terminology. "Credential injection" is one option I've seen floating around.

Not sure. I took this idea from the Deno sandboxing docs. They also do the exact same thing, different sandboxing mechanism though (I think Deno has it's own way of sandboxing subprocesses).

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#32

Post by alyxya »

kimixa wrote: post #6
alyxya wrote: post #3

Cool project, and I think there would be a lot of value in just logging all operations.

For just logging would it really give any more info than a trace already does?

Forgot about that, was mostly thinking about how AI agents with unrestricted permissions would ideally have some external logging and monitoring, so there would be a record of what it touched. A trace has all of the raw information, so some kind of wrapper around that would be useful.

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#33

Post by afshinmeh »

alyxya wrote: post #32
kimixa wrote: post #6

Earlier quoted context omitted.

For just logging would it really give any more info than a trace already does?

Forgot about that, was mostly thinking about how AI agents with unrestricted permissions would ideally have some external logging and monitoring, so there would be a record of what it touched. A trace has all of the raw information, so some kind of wrapper around that would be useful.

I'd like to know what level of details you'd expect. Something like `zerobox -- claude`, then you get an output log like this:

```

Read file /etc/passwd

Made network call to httpbin.org

Write file /tmp/access

```

etc.? I'm really interested to hear your thoughts and I will add that feature (I need something like that, too).

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#34

Post by mdavid626 »

afshinmeh wrote: post #29
mdavid626 wrote: post #28

I trust sandbox-exec more, or Docker on Linux. Those come from the OS, well tested and known. MITM proxy is nice idea to avoid leaking secrets. Isn’t it very brittle though? Anthropic changes some URL-s and it’ll break.

Thanks for sharing that. Zerobox _does_ use the native OS sandboxing mechanisms (e.g. seatbelt) under the hood. I'm not trying to reinvent the wheel when it comes to sandboxing. Re the URLs, I agree, that's why I added wildcard support, e.g. `*.openai.com` for secret injection as well as network call filtering.

How do you intercept network traffic on mac os? How do you fake certificates?

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#35

Post by kjok »

simonw wrote: post #24
kjok wrote: post #21

Earlier quoted context omitted.

> There are dozens of projects like this emerging right now. They all share the same challenge: establishing credibility. Care to elaborate on the kind of "credibility" to be established here? All these bazillion sandboxing tools use the same underlying frameworks for isolation (e.g., ebpf, landlock, VMs, cgroups, namespaces) that are already credible.

The problem is that those underlying frameworks can very easily be misconfigured. I need to know that the higher level sandboxing tools were written by people with a deep understanding of the primitives that they are building on, and a very robust approach to testing that their assumptions hold and they don't have any bugs in their layer that affect the security of the overall system. Most people are building on top…

> The problem is that those underlying frameworks can very easily be misconfigured.

Agreed. I'm sure a number of these sandboxing solutions are vibe-coded, which makes your concerns regarding misconfigurations even more relevant.

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#36

Post by afshinmeh »

mdavid626 wrote: post #34
afshinmeh wrote: post #29

Earlier quoted context omitted.

Thanks for sharing that. Zerobox _does_ use the native OS sandboxing mechanisms (e.g. seatbelt) under the hood. I'm not trying to reinvent the wheel when it comes to sandboxing. Re the URLs, I agree, that's why I added wildcard support, e.g. `*.openai.com` for secret injection as well as network call filtering.

How do you intercept network traffic on mac os? How do you fake certificates?

Zerobox creates a cert in `~/.zerobox/cert` on the first proxy run and reuses that. The MTIM process uses that cert to make the calls, inject certs, etc. This is actually done by the underlying Codex crate.

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#37

Post by mdavid626 »

afshinmeh wrote: post #29
mdavid626 wrote: post #28

I trust sandbox-exec more, or Docker on Linux. Those come from the OS, well tested and known. MITM proxy is nice idea to avoid leaking secrets. Isn’t it very brittle though? Anthropic changes some URL-s and it’ll break.

Thanks for sharing that. Zerobox _does_ use the native OS sandboxing mechanisms (e.g. seatbelt) under the hood. I'm not trying to reinvent the wheel when it comes to sandboxing. Re the URLs, I agree, that's why I added wildcard support, e.g. `*.openai.com` for secret injection as well as network call filtering.

You know, the thing is, that it is super easy to create such tools with AI nowadays. …and if you create your own, you can avoid these unnecessary abstractions. You get exactly what you want.

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#38

Post by mdavid626 »

afshinmeh wrote: post #36
mdavid626 wrote: post #34

Earlier quoted context omitted.

How do you intercept network traffic on mac os? How do you fake certificates?

Zerobox creates a cert in `~/.zerobox/cert` on the first proxy run and reuses that. The MTIM process uses that cert to make the calls, inject certs, etc. This is actually done by the underlying Codex crate.

Yeah, but how does the sandboxed process “know” that it has to go through the proxy? How does it trust your certificate? Is the proxy fully transparent?

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#39

Post by nonameiguess »

This is more a criticism of codex's linux-sandboxing, which you're just wrapping, but it's the first I've ever looked at it. I don't see how it makes sense to invoke bwrap as a forked subprocess. Bubblewrap can't do anything beyond what you can do with unshare directly, which you can simply invoke as a system call without needing to spawn a subprocess or requiring the user to have bwrap installed. It kinds of reeks of amateur hour when developers effectively just translate shell scripts into compiled languages by using whatever variant of "system" is available to make the same command invocations you would make through a shell, as opposed to actually using the system call API. Especially when the invocation is crafted from user input, there's a long history of exploits arising from stuff like this. Writing it in Rust does nothing for you when you're just using Rust to call a different CLI tool that isn't written in Rust.

Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls

#40

Post by simonw »

afshinmeh wrote: post #30
simonw wrote: post #27

Earlier quoted context omitted.

That's a really tough question. I always worry about credentials that are tucked away in ~/.folders in my home directory like in ~/.aws - but you HAVE to provide access to some of those like ~/.claude because otherwise Claude Code won't work. That's why rather than a default set I'm interested in an option where I get to approve things on first run - maybe something like this: zerobox --build-profile claude-profile.t…

Fantastic! I like that idea. I'm also exploring an option to define profiles, but also have predefines profiles that ships with the binary (e.g. Claude, then block all `.env` reads, etc.)

Being able to mix and match profiles would be neat.
Post reply on HN