3 ms·

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 t

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.

simonw 7mo ago
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.)
- afshinmeh 7mo ago
  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.)
  - simonw 7mo ago
    Being able to mix and match profiles would be neat.
    - afshinmeh 7mo ago
      Give me 2 days :)
      - gslepak 7mo ago
        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."
        afshinmeh 7mo ago
        I agree. What would be the ideal DX from your point of view?
        gslepak 7mo ago
        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/*

simonw 7mo ago

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

afshinmeh 7mo ago
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.)
- simonw 7mo ago
  Being able to mix and match profiles would be neat.
  - afshinmeh 7mo ago
    Give me 2 days :)
    - gslepak 7mo ago
      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."
      - afshinmeh 7mo ago
        I agree. What would be the ideal DX from your point of view?
        gslepak 7mo ago
        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/*