Live data from Hacker News

Go hard on agents, not on your filesystem

jai.scs.stanford.edu

271–280 of 374 posts

Re: Go hard on agents, not on your filesystem

#271

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.

> I've yet to be saved by an airbag or seatbelt. Is that justification to stop using them?

By now, getting a car without airbags would probably be more costly if possible, and the seatbelt takes 2s every time you're in a car, which is not nothing but is still very little. In comparison, analyzing all the dependencies of a software project, vetting them individually or having less of them can require days of efforts with a huge cost.

We all want as much security as possible until there's an actual cost to be paid, it's a tradeoff like everything else.

Re: Go hard on agents, not on your filesystem

#272

I am still amazed that people so easily accepted installing these agents on private machines. We've been securing our systems in all ways possible for decades and then one day just said: oh hello unpredictable, unreliable, Turing-complete software that can exfiltrate and corrupt data in infinite unknown ways -- here's the keys, go wild.

Not all of us. Figuring out bwrap was the first thing I did before running an agent. I posted on HN but not a single taker https://news.ycombinator.com/item?id=45087165 I have noticed it's become one of my most searched posts on Google though. Something like ten clicks a month! So at least some people aren't stupid.

Nice, sad how such stuff goes under in the sea of contentslop, thanks for posting!

Re: Go hard on agents, not on your filesystem

#273

Earlier quoted context omitted.

People were also dismissing concerns about build tooling automatically pulling in an entire swarm of dependencies and now here we are in the middle of a repetitive string of high profile developer supply chain compromises. Short term thinking seems to dominate even groups of people that are objectively smarter and better educated than average.

If anything I feel more in control of these agents than the millions of LOC npm or pip pull in to just show me a hello world

The load bearing word being "feel".

Re: Go hard on agents, not on your filesystem

#274
Well, I'm on Windows (+ Cygwin) and wrote a Dockerfile. It wasn't that hard. git branch + worktree + a docker container per project and I can work with copilot in --yolo mode (or claude --dangerously-skip-permissions, whichever). vscode is pretty smooth at installing the VS Code Server on first connection to a docker container, too, and I just open up the workspace in a minute.

Re: Go hard on agents, not on your filesystem

#275
post #201

Earlier quoted context omitted.

> The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. I feel like an integration with bubblewrap, the sandboxing tech behind Flatpak, could be useful here. Have all executed commands wrapped with a BW context to prevent and constrain access. https://github.com/containers/bubblewrap

Bubblewrap is exactly what the Claude sandbox uses. > These restrictions are enforced at the OS level (Seatbelt on macOS, bubblewrap on Linux), so they apply to all subprocess commands, including tools like kubectl, terraform, and npm, not just Claude’s file tools. https://code.claude.com/docs/en/sandboxing

Oh wow I'd have expected them to vibe-code it themselves. Props to them, bubblewrap is really solid, despite all my issues with the things built on top of it, what, Flatpak with its infinite xdg portals, all for some reason built on D-Bus, which extremely unluckily became the primary (and only really viable) IPC protocol on Linux, bwrap still makes a great foundation, never had a problem with it in particular. I tend to use it a bunch with NixOS and I often see Steam invoking it to support all of its runtimes. It's containers but actually good.

Re: Go hard on agents, not on your filesystem

#277

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.

So what does this do exactly? If it used "default deny" or "default allow" you wouldn't have both allow and deny rules...

Re: Go hard on agents, not on your filesystem

#278

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.

[dead]
Post reply on HN