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

21–30 of 108 posts

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

#21

Post by kjok »

simonw wrote: post #12

This looks really good - the CLI interface design is solid, and I especially like the secrets / network proxy pattern - but the thing it needs most is copiously detailed documentation about exactly how the sandbox mechanism works - and how it was tested. There are dozens of projects like this emerging right now. They all share the same challenge: establishing credibility. I'm loathe to spend time evaluating them unle…

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

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

#22

Post by afshinmeh »

volume_tech wrote: post #19

[flagged]

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

```

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

#23

Post by simonw »

afshinmeh wrote: post #20
simonw wrote: post #16

Earlier quoted context omitted.

This doesn't look like it's blacklisting to me. It's an allowlist system: --allow-net=api.openai.com # Explicitly allow access to that host --allow-write=config.txt # Explicitly allow write to that file

That's correct. The pattern is: reads allowed, write and network I/O blocked by default. ``` zerobox -- curl https://example.com Could not resolve host: example.com ```

Oh so it allows ALL file reads?

I'd feel safer with default-deny on reads as well, but I know from past experience that this gets tricky fast - tools like Node.js and uv and Python all have a bunch of files they need to be able to read that you might not predict in advance.

Might still be possible to do that in a DX-friendly way though, if you make it easy to manually approve reads the first time and use that to build a profile that can be reused on subsequent command invocations.

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

#24

Post by simonw »

kjok wrote: post #21
simonw wrote: post #12

This looks really good - the CLI interface design is solid, and I especially like the secrets / network proxy pattern - but the thing it needs most is copiously detailed documentation about exactly how the sandbox mechanism works - and how it was tested. There are dozens of projects like this emerging right now. They all share the same challenge: establishing credibility. I'm loathe to spend time evaluating them unle…

> 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 of Apple's sandbox-exec which is itself almost entirely undocumented!

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

#25

Post by afshinmeh »

simonw wrote: post #23
afshinmeh wrote: post #20

Earlier quoted context omitted.

That's correct. The pattern is: reads allowed, write and network I/O blocked by default. ``` zerobox -- curl https://example.com Could not resolve host: example.com ```

Oh so it allows ALL file reads? I'd feel safer with default-deny on reads as well, but I know from past experience that this gets tricky fast - tools like Node.js and uv and Python all have a bunch of files they need to be able to read that you might not predict in advance. Might still be possible to do that in a DX-friendly way though, if you make it easy to manually approve reads the first time and use that to buil…

I agree and you can deny all reads like this:

```

zerobox --deny-read=/ -- cat /etc/passwd

```

That being said, what the default DX shouldl be? What paths to deny by default? That's something I've been thinking about and I'd love to hear your thoughts.

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

#26

Post by simonw »

afshinmeh wrote: post #22
volume_tech wrote: post #19

[flagged]

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.

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

#27

Post by simonw »

afshinmeh wrote: post #25
simonw wrote: post #23

Earlier quoted context omitted.

Oh so it allows ALL file reads? I'd feel safer with default-deny on reads as well, but I know from past experience that this gets tricky fast - tools like Node.js and uv and Python all have a bunch of files they need to be able to read that you might not predict in advance. Might still be possible to do that in a DX-friendly way though, if you make it easy to manually approve reads the first time and use that to buil…

I agree and you can deny all reads like this: ``` zerobox --deny-read=/ -- cat /etc/passwd ``` That being said, what the default DX shouldl be? What paths to deny by default? That's something I've been thinking about and I'd love to hear your thoughts.

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.txt -- claude
The above command would create an empty claude-profile.txt file and then give me a bunch of interactive prompts every time Claude tried to access a file, maybe something like:

  claude wants to read ~/.claude/config.txt
  A) allow that file, D) allow full ~/.claude directory, X) exit
You would then clatter through a bunch of those the first time you run Claude and your decisions would be written to claude-profile.txt - then once that file exists you can start Claude in the future like this:

  zerobox --profile claude-profile.txt -- claude
(This is literally the first design I came up with after 30s of thought, I'm certain you could do much better.)

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

#29

Post by afshinmeh »

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.

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

#30

Post by afshinmeh »

simonw wrote: post #27
afshinmeh wrote: post #25

Earlier quoted context omitted.

I agree and you can deny all reads like this: ``` zerobox --deny-read=/ -- cat /etc/passwd ``` That being said, what the default DX shouldl be? What paths to deny by default? That's something I've been thinking about and I'd love to hear your thoughts.

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.)
Post reply on HN