3 ms·

"The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer." Is it uncommon to use dedicated VM

by mikece 5y ago

"The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer." Is it uncommon to use dedicated VMs for development for this very reason?

saurik 5y ago
> Is it uncommon to use dedicated VMs for development for this very reason? ... or on the production deployment's computer (which presumably is also "your" computer, and has a similar set of problems). (... or, if you go there, in production inside a VM, but in the same context and with access to everything from and all the memory and capabilities as the rest of the code you wrote, such as access to networking and the database or arbitrary CPU utilization.)
XorNot 5y ago
It's hard to make it practical without linking a whole lot of your local environment in. Remember it's death by a thousand cuts - every time you need some new thing, you just add it without considering the consequences too much. Probably lots of people doing this with their whole home directory linked in read/write. Recently I got a little concerned about this and made myself a basic safety harness with the bubblewrap[1] tool: rather then going all out, I just lock the mount namespace to readonly for everything except the directory I execute it in. Which is at least some protection against system mods or wide-spread home directory destruction. What's a lot more of a problem is trying to protect truly vital files - i.e. SSH keys and the like - which are also things you're likely to have bound into your VM anyway. selinux is a much better solution there (but so hard to administer as to be almost useless, though I do really like Fedora's default scopes and have used them successfully). [1] https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
kklisura 5y ago
Are we bringing back mainframes, yet?
skybrian 5y ago
I haven't actually done development within a VM. How practical is it? What's a good way to get started? (In this case, on a Mac.)
- mikece 5y ago
  When I was still a consultant I spun up new VMs for each client engagement -- both macOS and Windows -- using Parallels. When the engagement was over I would dump that to an external HDD. It meant over-spending on my MacBook Pro to have the SSD and RAM space to support multiple VMs but there was never any question of client work corrupting my system (or vice versa) or needing to wipe and reload my machine after a client engagement.
- nukemaster 5y ago
  You just do everything over ssh. It's one of the reasons everyone still like CLI/VT tools so much.
- mhoad 5y ago
  Codespaces is great in my experience. VSCode devcontainers is another very similar approach that will keep it on your machine but at least containerize the development environment raising the bar fairly significantly for a rogue package to do serious damage on your machine.
- deleted 5y ago
  [deleted]
mschuster91 5y ago
These days, for performance reasons most of the old "development VMs" (=Vagrant or worse) got replaced by Docker containers - orders of magnitude less effort. And in any case a dedicated VM is not going to protect you against attacks on your network, unless you go the full route of using a VPN to provide internet connectivity to the VM, and let's be honest almost no developer is going to do that simply because how much effort and maintenance it requires.
progx 5y ago
Linux solves a part of the problem, it has user accounts with restricted access. Create a dev account and run node within that account. This solves the full access problem, but not possible backdoors or leaks of your app.
- bogwog 5y ago
  And an even more convenient and more safe option is to use rootless containers via podman or [toolbx](https://containertoolbx.org/ https://containertoolbx.org/)

by mikece 5y ago

"The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer." Is it uncommon to use dedicated VMs for development for this very reason?

saurik 5y ago

> Is it uncommon to use dedicated VMs for development for this very reason? ... or on the production deployment's computer (which presumably is also "your" computer, and has a similar set of problems). (... or, if you go there, in production inside a VM, but in the same context and with access to everything from and all the memory and capabilities as the rest of the code you wrote, such as access to networking and the database or arbitrary CPU utilization.)

XorNot 5y ago

It's hard to make it practical without linking a whole lot of your local environment in. Remember it's death by a thousand cuts - every time you need some new thing, you just add it without considering the consequences too much. Probably lots of people doing this with their whole home directory linked in read/write. Recently I got a little concerned about this and made myself a basic safety harness with the bubblewrap[1] tool: rather then going all out, I just lock the mount namespace to readonly for everything except the directory I execute it in. Which is at least some protection against system mods or wide-spread home directory destruction. What's a lot more of a problem is trying to protect truly vital files - i.e. SSH keys and the like - which are also things you're likely to have bound into your VM anyway. selinux is a much better solution there (but so hard to administer as to be almost useless, though I do really like Fedora's default scopes and have used them successfully). [1] https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap

kklisura 5y ago

Are we bringing back mainframes, yet?

skybrian 5y ago

I haven't actually done development within a VM. How practical is it? What's a good way to get started? (In this case, on a Mac.)

mikece 5y ago
When I was still a consultant I spun up new VMs for each client engagement -- both macOS and Windows -- using Parallels. When the engagement was over I would dump that to an external HDD. It meant over-spending on my MacBook Pro to have the SSD and RAM space to support multiple VMs but there was never any question of client work corrupting my system (or vice versa) or needing to wipe and reload my machine after a client engagement.
nukemaster 5y ago
You just do everything over ssh. It's one of the reasons everyone still like CLI/VT tools so much.
mhoad 5y ago
Codespaces is great in my experience. VSCode devcontainers is another very similar approach that will keep it on your machine but at least containerize the development environment raising the bar fairly significantly for a rogue package to do serious damage on your machine.
deleted 5y ago
[deleted]

mschuster91 5y ago

These days, for performance reasons most of the old "development VMs" (=Vagrant or worse) got replaced by Docker containers - orders of magnitude less effort. And in any case a dedicated VM is not going to protect you against attacks on your network, unless you go the full route of using a VPN to provide internet connectivity to the VM, and let's be honest almost no developer is going to do that simply because how much effort and maintenance it requires.

progx 5y ago

Linux solves a part of the problem, it has user accounts with restricted access. Create a dev account and run node within that account. This solves the full access problem, but not possible backdoors or leaks of your app.

bogwog 5y ago
And an even more convenient and more safe option is to use rootless containers via podman or [toolbx](https://containertoolbx.org/ https://containertoolbx.org/)