6 ms·
Mounting a guest fs or syncing it to the host is rife with security footguns. I've developed almost exclusively in VMs for over a decade. One reason I use VMs
by chromakode 3y ago
Mounting a guest fs or syncing it to the host is rife with security footguns.
I've developed almost exclusively in VMs for over a decade. One reason I use VMs is to isolate the execution context from development and deployment. I used to passthrough from the host but poor performance and the lack of inotify are DX barriers. Passing through the FS to the host is a no-go because of subtle executable things like git-hooks that could enable sandbox escape.
The simplest and best approach I've found is to use a git remote on the host to push branches to/from the guest sandbox. I can commit on the sandbox fs and treat the host as an upstream remote. On the host I pull from the sandbox and push up to GitHub/etc. It's a bit more process but becomes second nature quickly and requires no extra tools. This also works well for remote servers.
Another approach I've used is lsyncd to sync files from the host to the guest (Mutagen is another cool syncing tool). In practice, though, I've found syncing to be a footgun too. It's too easy to edit a file on the host and blow away a change inside the guest with no undo. This is one reason I've found explicit git push / pull to be cleaner.
- makeitdouble 3y agoSecond this. Additionaly, having a VSCode server inside the VM is also a pretty sweet solution if VSCode is an option.
- binwiederhier 3y agoI find it exceptionally annoying to constantly commit and push, and entirely impossible if your IDE lives in the host. I have started to use Syncthing to share the entire workspace between host and VM and it works great. It's near instant, and even works between Windows and Linux, and it's local sync.
- exec1 3y agoI've never thought about using Syncthing for this, thanks for the idea!
- anotherhue 3y agoBeware the many conflict files that may result.
- binwiederhier 3y agoYeah the conflict files are no fun. You can, however, set up a sync location as "receiving only", which is neat if you have your IDE on the host and then just run things in the VM. Though I run it in 2-way mode because of the cache file syncing and such
- MonaroVXR 3y agoI'm using Rsync for this stuff.
- 0cf8612b2e1e 3y agoDo you run an IDE inside the guest or the host (through something like VS Code Remote)? Keeping the IDE inside the VM would feel more appropriate for your isolation, but would be a continual source of friction to keep IDE plugins/settings/tools in sync. Using a remote development workflow feels like it would eliminate many isolation guarantees. What does your VM provisioning setup look like?
- exec1 3y agoPhpStorm has the Jetbrains Gateway which allows running the IDE on the VM and connecting to it using a client on the host. However, I found this to be a rather clunky approach when working on a local VM. I could imagine it working well if you’re developing on a remote machine but for local use cases this feels like an overengineered approach.
- chromakode 3y agoYep! I run code-server inside the guest VM (or remote host). It's a great middle ground for snappy editing and isolation. Re: provisioning, really basic automation around KVM. I've been meaning to experiment with Firecracker for more transient runtime environments.
- exec1 3y ago> Passing through the FS to the host is a no-go because of subtle executable things like git-hooks that could enable sandbox escape. Could you please expand on this? I’m having trouble understanding this.
- exec1 3y agoAlso, while I’m at it – if you’re using VMs for isolating potentially insecure things then your threat model is obviously different. I should have mentioned that I’m using VMs mainly for practical reasons, e.g. for easily spinning up Ubuntu environments with my preferred toolset. If you’re worried about something escaping the VM sandbox via git-hooks then your use case is of course very different.
- chromakode 3y agoMy motivation for sandboxing is to fearlessly tinker with unfamiliar dependencies without thinking too deeply about the supply chain. Starting with isolation makes it safer to experiment, which is important to me for velocity.
- exec1 3y agoFair enough. I have clarified my use case at the top of my article to reflect my threat model. I don’t use the VM to run tricksy software I don’t trust so the sandboxing argument doesn’t really apply in my case (or rather it doesn’t apply any more than when running software directly on the host). All of the software I run on my VMs is the same software I would run on my host (if the host was Linux-based).
- chromakode 3y agoLikewise, fair enough. I appreciate you clarifying your threat model. I try to operate with low trust dev environments whenever possible, which is a major motivation for using VMs. It only takes one malicious npm or pip package for it to pay off.
- deleted 3y ago[deleted]
- lioeters 3y ago> Mutagen is another cool syncing tool Ah, interesting indeed. https://mutagen.io/documentation/synchronization https://mutagen.io/documentation/synchronization