4 ms·

What’s the best way to isolate VS Code+extensions? Do I have to fully run it in a VM? Use one of those third party flatpak builds (of unknown provenance) and di

What’s the best way to isolate VS Code+extensions? Do I have to fully run it in a VM? Use one of those third party flatpak builds (of unknown provenance) and disable networking via flatpak mechanisms?

pinoy420 2y ago
Considering vscode is itself malware. Probably nothing other than, yes, use a separate VM. I am an avid vscode advocate, but it is incredibly invasive and security ignorant.
flubbergusto 2y ago
I think containers is the way to go. Maybe on top of VM (defense in depth-swiss-cheese is the only way to go imo). Something like Qubes can be great for VMs. https://github.com/legobeat/l7-devenv/pull/153 https://github.com/legobeat/l7-devenv/pull/153 This works for me (which I do run in VMs also, yes). A key thing is some secrets like GH token and signing keys are not available even for the IDE and code in the environment requiring them. Like a poor-mans HSM, made for dev, kinda. Also LLM assistant gets access to exactly what it needs. No more, No Less. You can have your cake and eat it too. https://github.com/legobeat/l7-devenv https://github.com/legobeat/l7-devenv
- diggan 2y ago
  > I think containers is the way to go. Maybe on top of VM (defense in depth-swiss-cheese is the only way to go imo). If you go for a VM, why involved containers at all? What additional security you get from layering containers on top of VMs, compared to just straight up use a VM without containers?
  - groby_b 2y ago
    The theory is defense-in-depth. It's dubious if it buys you much, but any malware now needs a container escape and a VM escape. In reality, if it's target malware, it will, and if it's a mass-spray like a simple VSCode extension, it won't have either. (Nigerian Prince theory: You don't want to deal with the security-conscious people for a mass-attack)
  - flubbergusto 2y ago
    VMs are great for coarse isolation ("dev box", "web surfing", etc). A typical qubesos workstation would have a handful. In the setup I linked, separation is more fine-grained. Ephemeral container for each cargo/nodejs/python/go/gcc process. The IDE is in a separate container from its own language servers, and from the shell, which is separate from both the X server and the terminal window, the ssh agent, etc. Only relevant directories are shared. This runs my devenv with vscode fine on a 16GB RAM 8c machine. You'd need like 1T RAM and over 9000 cores to have that run smoothly with real VMs ;) Basically containers can give you far more domains (with better performance and weaker isolation) on the same host. The other upside is that the entire containerized setup can be run as unprivileged user. So an escape means they are still nerfed local user. A typical VM escape would have much shorter path to local root.
jbverschoor 2y ago
Run a container/vm for your project. Use VSCode only as an interface. Dev containers should do this, but I don't like the performance. I use my own docker-powered chroot container thingy https://github.com/jrz/container-shell https://github.com/jrz/container-shell
- ATechGuy 2y ago
  > Dev containers should do this, but I don't like the performance What kind of dev container have you tried? What is the source of perf overhead?
- mdaniel 2y ago
  If you mean "connect to VS code inside that container remotely," then https://news.ycombinator.com/item?id=42979467 https://news.ycombinator.com/item?id=42979467 is worth your read
Havoc 2y ago
Some extensions are client side so even VM won't work for all.

pinoy420 2y ago

Considering vscode is itself malware. Probably nothing other than, yes, use a separate VM. I am an avid vscode advocate, but it is incredibly invasive and security ignorant.

flubbergusto 2y ago

I think containers is the way to go. Maybe on top of VM (defense in depth-swiss-cheese is the only way to go imo). Something like Qubes can be great for VMs. https://github.com/legobeat/l7-devenv/pull/153 https://github.com/legobeat/l7-devenv/pull/153 This works for me (which I do run in VMs also, yes). A key thing is some secrets like GH token and signing keys are not available even for the IDE and code in the environment requiring them. Like a poor-mans HSM, made for dev, kinda. Also LLM assistant gets access to exactly what it needs. No more, No Less. You can have your cake and eat it too. https://github.com/legobeat/l7-devenv https://github.com/legobeat/l7-devenv

diggan 2y ago
> I think containers is the way to go. Maybe on top of VM (defense in depth-swiss-cheese is the only way to go imo). If you go for a VM, why involved containers at all? What additional security you get from layering containers on top of VMs, compared to just straight up use a VM without containers?
- groby_b 2y ago
  The theory is defense-in-depth. It's dubious if it buys you much, but any malware now needs a container escape and a VM escape. In reality, if it's target malware, it will, and if it's a mass-spray like a simple VSCode extension, it won't have either. (Nigerian Prince theory: You don't want to deal with the security-conscious people for a mass-attack)
- flubbergusto 2y ago
  VMs are great for coarse isolation ("dev box", "web surfing", etc). A typical qubesos workstation would have a handful. In the setup I linked, separation is more fine-grained. Ephemeral container for each cargo/nodejs/python/go/gcc process. The IDE is in a separate container from its own language servers, and from the shell, which is separate from both the X server and the terminal window, the ssh agent, etc. Only relevant directories are shared. This runs my devenv with vscode fine on a 16GB RAM 8c machine. You'd need like 1T RAM and over 9000 cores to have that run smoothly with real VMs ;) Basically containers can give you far more domains (with better performance and weaker isolation) on the same host. The other upside is that the entire containerized setup can be run as unprivileged user. So an escape means they are still nerfed local user. A typical VM escape would have much shorter path to local root.

jbverschoor 2y ago

Run a container/vm for your project. Use VSCode only as an interface. Dev containers should do this, but I don't like the performance. I use my own docker-powered chroot container thingy https://github.com/jrz/container-shell https://github.com/jrz/container-shell

ATechGuy 2y ago
> Dev containers should do this, but I don't like the performance What kind of dev container have you tried? What is the source of perf overhead?
mdaniel 2y ago
If you mean "connect to VS code inside that container remotely," then https://news.ycombinator.com/item?id=42979467 https://news.ycombinator.com/item?id=42979467 is worth your read

Havoc 2y ago

Some extensions are client side so even VM won't work for all.