Hacker News Reader

Comment by afshinmeh | Hacker News Reader

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.

View on HN

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/*

Reply on news.ycombinator.com