Hacker News Reader

Comment by jbverschoor | Hacker News Reader

Again, it’s blacklisting so kind of impossible to get right. I’ve looked at this many times, but in order for things to properly work, you have to create a huge, huge, huge, huge sandbox file.

Especially for your application that you any kind of Apple framework.

View on HN

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.

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

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 :)

The `--build-profile` / `--profile` thing is a good idea, but typically you'd want to just save all of the access that the program does without prompting.

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

I agree. What would be the ideal DX from your point of view?

The DX above from @simonw seems perfectly fine.

Let the user play with the app and after they exit the profile should contain all of the access attempts in a human readable format that's editable by the developer.

There might be many access attempts to folders in one directory, e.g.:

~/Documents/...

So instead of having a massive list of files it should be easy for developers to edit the profile to say, "Allow everything there", e.g. ~/Documents/*

That's interesting, thanks for sharing that. Could you elaborate a bit more? I'd like to understand the use case is a bit better.

Reply on news.ycombinator.com