Hacker News Reader

Comment by vqtska | Hacker News Reader

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?

View on HN

Privilege escalation (e.g. setuid), world-readable files might contain sensitive data, world-writeable files, unrestricted network access (including access to all locally running services)... If you have fully patched system without zero-days and it's configured in a perfect way, then, sure...

Container is quite like a "separate user" except you can explicitly define what it can access.

(Even if all your daemons have good auth, it's now quite common for _apps_ to open listening sockets without much auth...)

Also, many of these sandboxing solutions provide features like network allowlists and credential masking/injection

Sure, if you assume the agent will be hostile on you. I thought it's just so the agent doesn't accidentally rm -rf / on you

They do try privilege escalation unprompted.

The agent might install hostile software, e.g. a npm package. Unfortunately, very common problem nowadays.

There are documented instances of LLMs casually using LPEs in order to achieve an objective: https://xcancel.com/sluongng/status/2060746160558543217

And that's without anything like prompt injection happening.

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?

CVE-2026-53359 - https://github.com/V4bel/Januscape/blob/main/assets/write-up...

CVE-2026-43499 - https://nebusec.ai/research/ionstack-part-2/

Patched in Linux 7.1.3, which happens to be the exact kernel version I'm running. Update your kernels, folks.

> npm, pip, cargo and everything else

All that stuff should also go into the agent user's home directory.

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 totally enough...

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.

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.

VMs and containers are fairly isolated and reproducible. A separate user on your machine still depends on the programs installed locally.

And those installed programs could have vulnerabilities that just a non-root user account could still take advantage of. Perhaps not likely for an LLM to do, but more so if you let them loose on the internet and they end up coming across prompt injection that instructs exactly that :)

Well, for one, Debian and Debian-based distros make your home directory readable by everyone by default.

Security is riddled by traps. If you can afford best possible level of isolation, why not do it?

Yep, I broke locate when I made my home 700. Its user could not traverse my files anymore. I had to make it run as root. A better design would be to traverse each user home with that user id but apparently it assumes that the home dirs are 755.

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

Actually that doesn't just work on all systems and it breaks on others. The alternate user is actually guaranteed to work on all systems and it's built in

Seatbelt on macOS and Landlock over WSL2 on Windows 11. Landlock is also built-in, and WSL2 is a first-party downloadable component

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

There are two sides to this. The first is security, which plenty of comments already covered. The second, and the real one for me: my tests spin up Docker containers, and I was building a Kubernetes tool (argocd/flux style) that needs a real cluster in the sandbox. In a container that means Docker-in-Docker, which always felt hacky. A VM is just a normal Linux box where Docker and k8s run like they do everywhere else. A separate user can't give you that, it shares your one kernel and whatever's already installed on the host.

There is a reason why VMs even are a thing at all: they can offer better security guarantees than alternatives.

A separate user is a good start but LLM tests themselves show they can cleverly bypass guardrails if they figure out they are in a sandboxed environment of some kind, right?

So, I read those test results as: an LLM is less likely to do something crazy if it thinks it has the whole environment to itself.

On my Mac, every sudo requires either my fingerprint or password, and times out immediately.

Colleague recently told me his agent tried to sudo. It failed but it saw that docker with root is available and just used that. I don't quite remember what it did, I think editing something in /etc.

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

Mainly networking and namespaces, same reasons why we run services on docker instead of old multi-user setups

If you think those two contexts are equally secure, your machine is incredibly insecure and I hope you run daily incremental full system backups.

You have far too much data in unsecured locations, and you have far too little understanding of what an agent would do, to go "I trust whatever this user account will be doing on my machine".

In a corporate environment they may not have that option

But they can run arbitrary VMs?

Doesn't have to be arbitrary, and managing users requires a lot more nuance (endless permission toggling/configuring) than just running a VM that is more of a whitelist.

am I doing that once per project, or?

Reply on news.ycombinator.com