Comment by lucasluitjes
15 hours ago
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.
15 hours ago
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.
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.
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.
Or just use a separate user?
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.