Live data from Hacker News

Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

github.com

61–70 of 177 posts

Re: Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

#61
post #42

Earlier quoted context omitted.

You're missing the fact you'd be sharing a kernel with the sandboxed agent. Virtualization presents an infinitely smaller attack surface.

What kind of things are you even doing that the agent would try to perform a kernel exploit on you? I thought sandboxing is just to protect from the agent accidentally clearing your home directory. Side note, just 6 days ago a Linux VM escape exploit was disclosed.

I'm not worried about the agent at all. The VM is there to prevent it from clobbering files on my real system.

I'm worried about supply chain attacks on npm, pip, cargo and everything else. Don't want to get compromised if I install some stupid package.

My virtdev project has essentially split my computer into two systems: my "real" trusted system with software coming directly from my Linux distribition's repositories, and the VMs for everything else.

> just 6 days ago a Linux VM escape exploit was disclosed

Well, shit. Details?

Re: Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

#62
post #23

Earlier quoted context omitted.

you can also simply use Landlock and bwrap on Linux. Pi even has a plugin for that https://pi.dev/packages/pi-landstrip

Codex uses bwrap sandbox which is purely cosmetic - out-of-box it sees your ssh keys and can send it to remote server. It prevents agent from deleting outside files by mistake, but does nothing against malicious activity

that Pi extension, by contrast, gives you a popup whenever an agent tries to access something outside the current working directory and send a network request. that depends on configuration. also if agent tries to ssh into something that will also send a request for access, so child processes are covered

Re: Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

#65
post #60

Earlier quoted context omitted.

You're missing the fact you'd be sharing a kernel with the sandboxed agent. Virtualization presents an infinitely smaller attack surface.

If your threat model is that of a malicious agent that will use a 0-day LPE to get root and exfiltrate all of your SSH keys, virtualization makes sense. But then, I wouldn't run such an agent at all, if not specifically in the context of malware analysis. If you're just concerned about "agent messing up and taking the rules in some markdown files more laxly than I would have", then running it as a seperate user is to…

Threat model is supply chain attacks on unmaintained package repositories like npm, pip and cargo. Everything on my host comes from my Linux distribution's repositories. Everything else gets virtualized with extreme prejudice. I'll even virtualize my Steam games one of these days.

Re: Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

#67
post #15

I still don't understand the point of all these VMs and containers for agents. Just create a separate user on your machine without sudo privileges, switch to it in your terminal and run all the agents you want without it being able to reach your files. What am I missing?

And why would I do that when I can create a vm from a snapshot and be done in 30 seconds?

Re: Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

#68
When firing up agent VMs for my personal projects, I tried to completely separate SSH keys as well. Surprisingly annoying to have multiple keys for, say GitHub, and restrict the agent to use a deploy key.

I saw this project enables ssh-agent forwarding, so my question; is this a non-issue to begin with? Or just not your focus currently.

Re: Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop

#69
post #60

Earlier quoted context omitted.

You're missing the fact you'd be sharing a kernel with the sandboxed agent. Virtualization presents an infinitely smaller attack surface.

If your threat model is that of a malicious agent that will use a 0-day LPE to get root and exfiltrate all of your SSH keys, virtualization makes sense. But then, I wouldn't run such an agent at all, if not specifically in the context of malware analysis. If you're just concerned about "agent messing up and taking the rules in some markdown files more laxly than I would have", then running it as a seperate user is to…

IMO the threat model is more letting the agent loose on issues/PRs in a public Github repo and it getting tricked into running a malicious payload.
Post reply on HN