Personally I would probably always reach for a docker container if I want a sandboxed command that can run identically anywhere. I appreciate that alternate sandboxing tools can reduce some of the heavier parts of docker though (i.e. building or downloading the correct image) How would you compare this tool to say bubblewrap https://github.com/containers/
[flagged]
Show HN: Zerobox – Sandbox any command with file, network, credential controls
81–90 of 108 posts
Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#82Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#83Hey - I'd love for you to add a documented / standard way to use this inside dockers so we can use build on it for various agentic efforts. I've solved getting bubblewrap to work inside a docker once for the nanobot project, but the folks there are dragging their feet on incorporating sandboxing. https://github.com/HKUDS/nanobot/pull/1940
I'd like to hear your thoughts.
Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#84Earlier quoted context omitted.
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.
I'm thinking the LocalLLM crowd should take their LLMs to trying to demolish these sandboxes.
Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#85Hey - I'd love for you to add a documented / standard way to use this inside dockers so we can use build on it for various agentic efforts. I've solved getting bubblewrap to work inside a docker once for the nanobot project, but the folks there are dragging their feet on incorporating sandboxing. https://github.com/HKUDS/nanobot/pull/1940
I've been testing this on Docker today, including the credential injection, env vars, net calls control. I will add more docs but one interesting use case would be to have something like `zerobox --profile nanoclaw -- nanoclaw`, or something similar. I'd like to hear your thoughts.
Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#86Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#87Earlier quoted context omitted.
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!
Thanks, I think I'll go with "credential injection" since the word "tokenization" has other meanings that I find confusing here.
Re: Show HN: Zerobox – Sandbox any command with file, network, credential controls
#88Earlier quoted context omitted.
Being able to mix and match profiles would be neat.
Give me 2 days :)
Programs will access many files and directories on startup, and it would be extremely tedious to have to manually approve each one. So you'd auto-approve all and save them to the profile. This is TOFU principles applied to sandboxing. The assumption being that "this first time I run it naked, it's unlikely to do anything malicious, let me enforce that behavior for the future."