Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

Post reply on HN
Print view View original

191–200 of 374 posts

Re: Go hard on agents, not on your filesystem

#191

Post by kstenerud »

mazieres wrote: post #48
rsyring wrote: post #42

I've been reviewing Agent sandboxing solutions recently and it occurred to me there is a gaping vector for persistent exploits for tools that let the agent write to the project directory. Like this one does. I had originally thought this would ok as we could review everything in the git diff. But, it later occurred to me that there are all kinds of files that the agent could write to that I'd end up executing, as the…

It's a good point. Maybe I should add an option to make certain directories read-only even under the current working directory, so that you can make .git/ read-only without moving it out of the project directory. You can already make CWD an overlay with "jai -D". The tricky part is how to merge the changes back into your main working directory.

This is the problem yoloAI (see below comment) is built around. The merge step is `yoloai diff` / `yoloai apply`: the agent works against a copy of your project inside the container, you review the diff, you decide what lands.

jai's -D flag captures the right data; the missing piece is surfacing it ergonomically. yoloAI uses git for the diff/apply so it already feels natural to a dev.

One thing that's not fully solved yet: your point about .git/hooks and .venv being write vectors even within the project dir. They're filtered from the diff surface but the agent can still write them during the session. A read-only flag for those paths (what you're considering adding to jai) would be a cleaner fix.

Re: Go hard on agents, not on your filesystem

#192

Post by yobert »

0xbadcafebee wrote: post #144

If it has a big splash page with no technical information, it's trying to trick you into using it. That doesn't mean it isn't useful, but it does mean it's disingenuous. This particular solution is very bad. To start off with, it's basically offering you security, right? Look, bars in front of an evil AI! An AI jail! That's secure, right? Yet the very first mode it offers you is insecure. The "casual" mode allows rea…

It is a bit better than you're saying. When you fire it up, you can see that it does have a list of common credential areas that it hides from the jail. It seems to hide:

    .aws  .azure  .bash_history .config  .docker  .git-credentials  .gnupg  .jai  .local  .mozilla  .netrc  .password-store  .ssh  .zsh_history
It's a humorous attempt in a sense, but better than nothing for sure!

Re: Go hard on agents, not on your filesystem

#194

Post by mixedbit »

I work on a sandboxing tool similarly based on an idea to point the user home dir to a separate location (https://github.com/wrr/drop). While I experimented with using overlayfs to isolate changes to the filesystem and it worked well as a proof-of-concept, overlayfs specification is quite restrictive regarding how it can be mounted to prevent undefined behaviors.

I wonder if and how jai managed to address these limitations of overlayfs. Basically, the same dir should not be mounted as an overlayfs upper layer by different overlayfs mounts. If you run 'jai bash' twice in different terminals, do the two instances get two different writable home dir overlays, or the same one? In the second case, is the second 'jai bash' command joining the mount namespace of the first one, or create a new one with the same shared upper dir?

This limitation of overlays is described here: https://docs.kernel.org/filesystems/overlayfs.html :

'Using an upper layer path and/or a workdir path that are already used by another overlay mount is not allowed and may fail with EBUSY. Using partially overlapping paths is not allowed and may fail with EBUSY. If files are accessed from two overlayfs mounts which share or overlap the upper layer and/or workdir path, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.'

Re: Go hard on agents, not on your filesystem

#195

Post by tokioyoyo »

fc417fc802 wrote: post #186
tokioyoyo wrote: post #102

Earlier quoted context omitted.

> “high profile developer supply chain compromises” And nothing big has happened despite all the risks and problems that came up with it. People keep chasing speed and convenience, because most things don’t even last long enough to ever see a problem.

I've yet to be saved by an airbag or seatbelt. Is that justification to stop using them? How near a miss must we have (and how many) before you would feel that certain practices surrounding dependencies are inadvisable? A number of these supply chain compromises had incredibly high stakes and were seemingly only noticed before paying off by lucky coincidence.

> How near a miss must we have (and how many)

The fun part is, there have been a lot of non-misses! Like a lot! A ton of data have been exfiltrated, a lot of attacks, and etc. In the end... it just didn't matter.

Your analogy isn't really apt either. My argument is closer to "given in the past decade+, nothing of worth has been harmed, should we require airbags and seatbelts for everything?". Obviously in some extreme mission critical systems you should be much smarter. But in 99% cases it doesn't matter.

Re: Go hard on agents, not on your filesystem

#196

Post by torarnv »

I’m using https://github.com/torarnv/claude-remote-shell for this, which runs Claude’s Bash tool on a remote machine but leaves Claude running locally otherwise.

I’ve found it to be a good balance for letting Claude loose in a VM running the commands it wants while having all my local MCPs and tools still available.

Re: Go hard on agents, not on your filesystem

#197

Post by mcv »

ethanwillis wrote: post #190
throwaway2027 wrote: post #185

Earlier quoted context omitted.

All of which is useless when it just starts using big blocks of python instead. You need filesystem sandboxing for the python interpreter too.

What we need is a capabilities based security system. It could write all the python, asm, whatever it wants and it wouldn't matter at all if it was never given a reference to use something it shouldn't.

Isn't this already possible? Give it its own user account with write access to the project directory and either read access or no access outside it.

Re: Go hard on agents, not on your filesystem

#198

Post by bit_logic »

AnotherGoodName wrote: post #15

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

The default: https://code.claude.com/docs/en/sandboxing#filesystem-isolat... already restricts writes to only the current folder. I can understand adding the "denyRead" for the home folder for additional security, but the other three seems redundant considering the default behavior.

Re: Go hard on agents, not on your filesystem

#199

Post by OJFord »

varl wrote: post #182
AnotherGoodName wrote: post #15

Add this to .claude/settings.json: { "sandbox": { "enabled": true, "filesystem": { "allowRead": ["."], "denyRead": ["~/"], "allowWrite": ["."], "denyWrite": ["/"] } } } You can change the read part if you're ok with it reading outside. This feature was only added 10 days ago fwiw but it's great and pretty much this.

I've had issues with the sandbox feature, both on linux (archlinux) and two macos machines (tahoe). There is an open issue[1] on the claude-code issue tracker for it. I'm not saying it is broken for everyone, but please do verify it does work before trusting it, by instructing Claude to attempt to read from somewhere it shouldn't be allowed to. From my side, I confirmed both bubblewrap and seatbelt to work independen…

Its seccomp filter also doesn't work, at all: https://github.com/anthropics/claude-code/issues/24238
Post reply on HN