[chromakode]

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.

[binwiederhier]

I 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]

I've never thought about using Syncthing for this, thanks for the idea!

[anotherhue]

Beware the many conflict files that may result.

[binwiederhier]

Yeah 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]

I'm using Rsync for this stuff.

[exec1]

> 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]

Also, 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]

My 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]

Fair 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]

Likewise, 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.

[exec1]

Yeah, I hear you. I try to avoid pulling NPM packages that I don’t know so I’m not really interested in containing software for security purposes.

Of course, there’s also the question of dependencies. If I’m working on a project that I trust that pulls in hundreds of NPM dependencies, I implicitly trust that the project deemed those dependencies safe to pull in. It would be impossible to always operate on the assumption that you’re potentially pulling in hundreds of malicious packages so the chain of trust has to take over at some point.

However, I imagine you were more or less referring to singular projects that you don’t fully trust and like to experiment with in which case I agree with you and would probably use a VM without any kind of file sharing tbh.

[exec1]

An addendum: if you’re worried about the guest setting up a malicious git hook that your host would then execute, then your threat model is obviously very different from mine. Perhaps I should have clarified that I’m running code that I trust inside the VM so sandbox escape is not really a security issue in my case (but rather an operational one if, for example, a misbehaving script causes havoc on the host in this way).

[chromakode]

For example, let's say I've got a git repo on a guest VM and I'm syncing the dir to the host. If I run `git push` on the host (because my ssh key is there), it implicitly runs any pre-push script dropped there by the guest, defeating any isolation.

[0cf8612b2e1e]

Do 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]

PhpStorm 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]

Yep! 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.

[makeitdouble]

Second this.

Additionaly, having a VSCode server inside the VM is also a pretty sweet solution if VSCode is an option.

[lioeters]

> Mutagen is another cool syncing tool

Ah, interesting indeed.

https://mutagen.io/documentation/synchronization