I've tried the same but the graphics performance was too slow (no GPU acceleration). The current setup is to use a virtual machine but connect to it via VS Code's Remote SSH extension from the host.

I hope you've turned off VS Code's "workspace trust" settings.

https://code.visualstudio.com/docs/editor/workspace-trust

Sometimes but I wonder to what degree it actually matters. Tasks, debuggers, extensions etc. run in the context of the VM, not the host. The Remote SSH extension turns VS Code into a "thin" client which presents pretty much just the UI.

https://code.visualstudio.com/docs/remote/ssh

Readme says: https://marketplace.visualstudio.com/items?itemName=ms-vscod...

> A compromised remote could use the VS Code Remote connection to execute code on your local machine.

So I would say that it might be a bit harder for an attacker to gain access to your local machine, but you should not rely on it, because it's more like security by obscurity.

Well damn. I was under the impression that the communication channel uses/accepts only well defined VSCode specific messages related to the UI...

Darn. Maybe the solution is to use vs-code client in the browser? Like vscode.dev or https://github.com/coder/code-server ? It limits what keyboard shortcuts and extensions are available, but at least it's in a secure sandbox on the client side.

With Qubes, you can do GPU passthrough: https://forum.qubes-os.org/t/another-2-gpu-passthrough-post/....

Virtual is part of a solution but not the key: the key is to separate your dev env from your real life/business environment -- including all your personal and professional business data and web accounts that expose your financials and private data.

If you log into your email from the virtual machine, you are at risk.

I think that separation is the point of the VM. Do the dev work in the VM, don't give it sensitive info about yourself.

That protects me (the software developer/maintainer) to some degree, but does nothing to protect the users of the software I am maintaining.

As long as your are creating web applications then browsers are pretty good at limiting blast radius of a single attacked website. Well, at least until attacker discovers that he can inject some fancy phishing into trusted site.

With local development environment it is a bit different, because unless you are running build/test etc. in a container/vm/sandbox, then attacker has access to all of your files, especially web browser data.

Development should be more exploratory and experimental than prod. For the past decade I've had a similar strategy: I freely install and demo new dependencies on separate dev hardware (or a VM when I'm on the road). Then I code review (incl. locked dependencies) and deploy from a trusted environment with reduced supply chain exposure.

The only place I log into from the VM is Github, protected by 2FA in case any malware gets my password.

The malware will just take the session cookie. Some actions still require 2FA approval, but it’s not many, iirc.

So the malware can delete all your projects or inject malware into them, but thankfully it won't be able to log in again later?

Then you might be interested in Qubes OS: https://qubes-os.org.

That's why I chose it. A lot of peace of mind there.

Full disclosure, I am a co-founder at Phylum.

We are actively working on a solution that will fully sandbox package installations for npm, yarn, poetry and others.

It's rolled up as part of our core CLI [1], but is totally open source [2]:

[1] https://github.com/phylum-dev/cli [2] https://github.com/phylum-dev/birdcage

Sounds awesome.

Though I’m not sure of the solution really is / should be increased sandboxing.

The alternative may be a rethinking of the increasingly smaller packages. Maybe it’s better to have few large packages maintained by reputable organisations or personalities?

The problem is large, sprawling and complex. In an ideal case, we'd have high quality packages maintained by reputable people/organizations. But today this just isn't true. Open source takes contributions from a large number of unknown authors/contributors with motivations that may or might night align with your own.

We really need a defense in depth approach here. Sandbox where it makes sense, perform analysis of code being published, consider author reputation, etc.

Why is there so much discussion about sandboxing? Why wouldn't I put some malicious code in the package itself limiting myself to installation only?

A lot of the malware targeting developers is leveraging the installation hooks as the execution mechanism. So sandboxing the install helps stop this particular attack vector - which is why it gets talked about so much.

If you put code in the package itself, this would side step the "installation" sandbox. However we're also doing analysis of all packages introduced to the ecosystem to uncover things that are hiding in the packages themselves.

So you're right, we need a defense in depth approach here.

I think this is a very good idea. It should actually be built into the OS. I know of BSD jails, but not sure what else there is for Linux/Windows/MacOS.

> Only one typo in an import statement up the dependency chain and you’d be compromised.

Doesn’t even have to be a typo if the actual project is compromised. Like one of the 100s of NPM modules without 2FA for publishing.

This is a good approach, though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys? It'll limit the fallout of getting owned to anything reachable from Github (is it against Github's TOS to have multiple accounts?), less if you have 2FA (does there exist 2FA for SSH keys (I don't mean passphrases)?), but I think it would be better for just my build/run/test cycles to be cordoned off into their own universe, with a way for just the source code itself to cross the boundary.

It might be too cumbersome for most, and I might be more paranoid than average, but each project for me means a fresh VM, a new Keepass database and dedicated accounts. Then again I work mostly in ops, and I've seen first hand how badly things can go wrong so isolation and limiting blast radius takes precedence over daily convenience for me.

Could you please share some resources/tactics for protecting your host machine from these development VMs? If I were to do this, I would want some assurances (never 100%) that my host is protected from the VM to the best of my ability.

(If it makes any difference, I would probably be using VMWare Workstation Pro)

I can't give you what you're looking for. You need to decide on the trade offs for yourself. There will always be a risk. Directed attacks can get out of VMs. You could slip up and log into a personal account inside the VM.

I tried to make it clear in my reply that I understood there are no guarantees. What I’m asking is if you have any guidance on reducing the likelihood of these attacks succeeding

That does sound incredibly cumbersome. I suppose that means you are an ace at provisioning machines.

How do you move data in/out of the guests? I always found that part of interacting with VMs to be annoyingly painful.

There are always trade offs. You do get better at things you do a lot. My mother won't use a password vault because copying and pasting is too much work for her. I'd just rather pay with my time and inconvenience than one day find out some python package I fiddled with for a late night project once means I need to call my bank.

SSH.

Doesn't even need to be command line, you can just open remote addresses in your favourite graphical file browser, at least under Linux.

Why wouldn't you use disposable VMs [0] and secure inter-VM copy [1] on Qubes OS instead? It's much less cumbersome and more secure.

[0] https://www.qubes-os.org/doc/how-to-use-disposables/

[1] https://www.qubes-os.org/doc/how-to-copy-and-move-files/

That sounds like precisely QubeOS's use case.

> though presumably the VM still has access to your Github credentials (via the browser) and your SSH keys?

Not in Qubes OS:

https://github.com/Qubes-Community/Contents/blob/master/docs...

https://www.qubes-os.org/doc/split-gpg/

> does there exist 2FA for SSH keys (I don't mean passphrases

Yes. Yubikey. ecdsa-sk key requires you to tap yubikey to have a working key. It consists of 2 parts - a private key file, but which is useless without yubikey. https://developers.yubico.com/SSH/

https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...

Github offers fine grained personal access tokens. https://docs.github.com/en/authentication/keeping-your-accou...

Azure DevOps does it too

Far as I know, in AzDO you can't even limit a PAT to a single project/repository. Not good for limiting access cause even a read only can see private stuff in other projects. You might create a specific account and assign to only that project but what a pain.

This is the way.

Packj sandbox [1] offers "safe installation" of PyPI/NPM/Rubygems packages. It shows you a preview of file system changes that installation will make and can also block arbitrary network communication during installation (uses an allow-list). Disclaimer: I've been building Packj for over an year now.

1. https://github.com/ossillate-inc/packj/blob/main/packj/sandb...

Only secures installation, not runtime, but still helpful. I'm not a package maintainer, but I do wish that packages were not allowed to run any code at install-time.

This is goid defense in depth measure but doesn't solve one fundamental issue. You might be protected during developement by the sandbox but your users are not necessarily. I think we as developers should not give any sotware we do not trust to our users.

I'm following the same workflow. I use a Linux host and then a Linux guest with OpenGL acceleration on virt-manager. I do all my development and browsing inside the VM. I do not trust any of the npm packages or PIP packages. Any personal stuff like banking, password manager, Nextcloud goes on the host.

With modern virtio interfaces for network, disk and graphics practically giving near metal performance, there's no reason to not utilize VMs for development.

Similar. I run text editor on the main OS but run language server in the requisite environment with all the requirements in a container.