[lucasluitjes]

> What you’re NOT protecting against:

> a malicious AI trying to escape the VM (VM escape vulnerabilities exist, but they’re rare and require deliberate exploitation)

No VM escape vulns necessary. A malicious AI could just add arbitrary code to your Vagrantfile and get host access the first time you run a vagrant command.

If you're only worried about mistakes, Claude could decide to fix/improve something by adding a commit hook. If that contains a mistake, the mistake gets executed on your host the first time you git commit/push.

(Yes, it's unpleasantly difficult to truly isolate dev environments without inconveniencing yourself.)

[johndough]

    > A malicious AI could just add arbitrary code to your Vagrantfile
    > [...]
    > Claude could decide to fix/improve something by adding a commit hook.

You can fix this by confining Claude to a subdirectory (with Docker volume mounts, for example):

    repository/
    ├── sandbox <--- Claude lives in here
    │   └── main.py <--- Claude can edit this
    └── .git <--- Claude can not touch this

[embedding-shape]

Doesn't this assume you bi-directionally share directories between the host or the VM? Or how would the AI inside the VM be able to write to your .git repository or Vagrantfile? That's not the default setup with VMs (AFAIK, you need to explicitly use "shared directories" or similar), nor should you do that if you're trying to use VM for containment of something.

I basically do something like "take snapshot -> run tiny vm -> let agent do what it does -> take snapshot -> look at diff" for each change, restarting if it doesn't give me what I wanted, or I misdirected it somehow. But there is no automatic sync of files, that'd defeat the entire point of putting it into a VM in the first place, wouldn't it?

[lucasluitjes]

It's the default behaviour for Vagrant. You put a Vagrantfile in your repo, run `vagrant up` and it creates a VM with the repo folder shared r+w to `/vagrant` in the VM.

[embedding-shape]

That's because Vagrant isn't "VM", it's a developer tool you use locally that happens to use VMs, and it was created in a era where 1) containers didn't exist as they do today, 2) packaging and distribution for major languages wasn't infected with malware and 3) LLM agents now runs on our computers and they are kind of dumb sometimes and delete stuff.

With new realities, new workflows have to be adopted. Once malware started to appear on npm/pypi, I started running all my stuff in VMs unless it's something really common and presumed vetted. I do my banking on the same computer I do programming, so it's either that or get another computer.

[lucasluitjes]

Agree with all of that, especially modern supply chain risk (imho the more important reason to opt for VM isolation rather than containerization). But the original article specifically talks Vagrant as an isolation solution, and describes it as not protecting against VM escape, but also that guest-to-host 0day is rare.

Hence pointing out that VM escape is a lot easier than that if your VM management tool syncs folders the way that Vagrant does by default.

[pluralmonad]

Or just use a separate user?

[embedding-shape]

That's another option. Or containers. Or cloud hosts. Point is to stop doing bidirectional syncing of directories when you're trying to do isolation.

[dist-epoch]

Another way is malicious code gets added to the repo, if you ever run the repo code outside the VM you get infected.

[martinflack]

Maybe before 'vagrant up' you run 'sudo chattr +i Vagrantfile' to make it immutable. Seems to disallow removal of the attribute inside the VM, but allow it outside.

[redactsureAI]

ec2 node?

[eli]

Or just a VM that doesn't share so much with your host. Just makes for a more annoying dev experience.

[dist-epoch]

Why do you need to share anything? Code goes through GitHub - VM has it's own repo clone, if you need data files, you mount them read-only in the VM, have a read-write mount for output data.

[eli]

I'd like to be able to see and edit the code in an IDE

[redactsureAI]

I work every day in a remote node with an IDE. VS code has a really simple extension you can run a full ide with file system control in a remote server. Git clone your files, open up VS code.

[boppo1]

Eh, I stuck it in a docker container with pass-thru to my repo directory and I feel pretty safe about letting it fly.

Then again I dont work on anything serious.