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

41–50 of 108 posts

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

#41

Post by afshinmeh »

mdavid626 wrote: post #38
afshinmeh wrote: post #36

Earlier quoted context omitted.

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?

Oh I see. It inject HTTP_PROXY/HTTPS_PROXY/etc. env vars into the process so that all sandboxed subprocesses go through the proxy.

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

#42

Post by afshinmeh »

simonw wrote: post #40
afshinmeh wrote: post #30

Earlier quoted context omitted.

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.

Give me 2 days :)

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

#43

Post by afshinmeh »

nonameiguess wrote: post #39

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 o…

Thanks for sharing this, I read your comment multiple times. What would be the alternative though? It is true that the program being written in Rust doesn't solve the problem of spawning subprocesses, but what's the alternative in that case?

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

#44

Post by blanched »

afshinmeh wrote: post #41
mdavid626 wrote: post #38

Earlier quoted context omitted.

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?

Oh I see. It inject HTTP_PROXY/HTTPS_PROXY/etc. env vars into the process so that all sandboxed subprocesses go through the proxy.

What if the program doesn’t respect those env vars? Can Zerobox still block network calls in that case?

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

#48

Post by TheTaytay »

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.

simonw, I have been seeing "credential injection" and "credential tokenizing" (a la tokenizer: https://github.com/superfly/tokenizer). I'm also seeing credential "surrogates" mentioned.

I am currently working on a mitm proxy for use with devcontainers to try to implement this pattern, but I'm certainly not the only one!

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

#49

Post by afshinmeh »

blanched wrote: post #44
afshinmeh wrote: post #41

Earlier quoted context omitted.

Oh I see. It inject HTTP_PROXY/HTTPS_PROXY/etc. env vars into the process so that all sandboxed subprocesses go through the proxy.

What if the program doesn’t respect those env vars? Can Zerobox still block network calls in that case?

Great question! On Linux, yes, network namespaces enforce that and all net traffic goes through the proxy. Direct connections are blocked at the kernel level even if the program ignores proxy env vars, but I will test this case a bit more (unsure how to though, most network calls would respect HTTPS_PROXY and other similar env vars).

That being said, the default behaviour is no network, so nothing will be routed if it's not allowed regardless of whether the sandboxed process respects env vars or not.

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

#50

Post by EGreg »

This is really useful! How well does it compare though to Docker etc.

Because I am worried about sandbox escapes. This is what we currently use to sandbox JS inside Browsers and Node (without anything extra) : https://github.com/Qbix/Platform/blob/main/platform/plugins/...

I like tools like this, but they all seem to share the same underlying shape: take an arbitrary process and try to restrict it with OS primitives + some policy layer (flags, proxies, etc).

That works, but it also means correctness depends heavily on configuration, i.e. you’re starting with a lot of ambient authority and trying to subtract from it enforcement ends up split across multiple layers (kernel, wrapper, proxy)

An alternative model is to flip it: Instead of sandboxing arbitrary programs, run workflows in an environment where there is no general network/filesystem access at all, and every external interaction has to go through explicit capabilities.

In that setup, there’s nothing to "block" because the dangerous primitives aren’t exposed, execution can be deterministic/replayable, so you can actually audit behavior. Thus, secrets don’t enter the execution context, they’re only used at the boundary

It feels closer to capability-based systems than traditional sandboxing. Curious how people here think about that tradeoff vs OS-level sandbox + proxy approaches.

Post reply on HN