5 ms·

I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major packag

I started to develop only inside VMs, with a full Desktop, IDE, browser etc. inside the virtual machine. There have been to many contaminations of major package repos lately. Only one typo in an import statement up the dependency chain and you’d be compromised.

fsflover 4y ago
Then you might be interested in Qubes OS: https://qubes-os.org https://qubes-os.org.
- orblivion 4y ago
  That's why I chose it. A lot of peace of mind there.
lupire 4y ago
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.
- orblivion 4y ago
  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.
- hollerith 4y ago
  That protects me (the software developer/maintainer) to some degree, but does nothing to protect the users of the software I am maintaining.
  - suchar 4y ago
    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.
  - chromakode 4y ago
    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.
- coffeeblack 4y ago
  The only place I log into from the VM is Github, protected by 2FA in case any malware gets my password.
  - ylk 4y ago
    The malware will just take the session cookie. Some actions still require 2FA approval, but it’s not many, iirc.
  - remram 4y ago
    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?
frankjr 4y ago
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.
- inetknght 4y ago
  I hope you've turned off VS Code's "workspace trust" settings. https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust
  - frankjr 4y ago
    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 https://code.visualstudio.com/docs/remote/ssh
    - suchar 4y ago
      Readme says: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh 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.
      - frankjr 4y ago
        Well damn. I was under the impression that the communication channel uses/accepts only well defined VSCode specific messages related to the UI...
        collinmanderson 4y ago
louislang 4y ago
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 https://github.com/phylum-dev/cli [2] https://github.com/phylum-dev/birdcage https://github.com/phylum-dev/birdcage
- comboy 4y ago
  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?
  - louislang 4y ago
    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.
- coffeeblack 4y ago
  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?
  - louislang 4y ago
    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.
koolba 4y ago
> 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.
kibwen 4y ago
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.
- namaria 4y ago
  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.
  - 0cf8612b2e1e 4y ago
    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.
    - namaria 4y ago
      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.
    - fbhabbed 4y ago
      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.
  - 4y ago
secondcoming 4y ago
This is the way.
ashishbijlani 4y ago
Packj sandbox [1] offers "safe installation" of PyPI/NPM/Rubygems packages. 1. https://github.com/ossillate-inc/packj/blob/main/packj/sandbox/README.md https://github.com/ossillate-inc/packj/blob/main/packj/sandb... It DOES NOT require a VM/Container; uses strace. 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 a year now.
- collinmanderson 4y ago
  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.
weinzierl 4y ago
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.
Bright_Machine 4y ago
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.
throwaway290 4y ago
Similar. I run text editor on the main OS but run language server in the requisite environment with all the requirements in a container.

fsflover 4y ago

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

orblivion 4y ago
That's why I chose it. A lot of peace of mind there.

lupire 4y ago

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.

orblivion 4y ago
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.
hollerith 4y ago
That protects me (the software developer/maintainer) to some degree, but does nothing to protect the users of the software I am maintaining.
- suchar 4y ago
  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.
- chromakode 4y ago
  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.
coffeeblack 4y ago
The only place I log into from the VM is Github, protected by 2FA in case any malware gets my password.
- ylk 4y ago
  The malware will just take the session cookie. Some actions still require 2FA approval, but it’s not many, iirc.
- remram 4y ago
  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?

frankjr 4y ago

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.

inetknght 4y ago
I hope you've turned off VS Code's "workspace trust" settings. https://code.visualstudio.com/docs/editor/workspace-trust https://code.visualstudio.com/docs/editor/workspace-trust
- frankjr 4y ago
  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 https://code.visualstudio.com/docs/remote/ssh
  - suchar 4y ago
    Readme says: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh 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.
    - frankjr 4y ago
      Well damn. I was under the impression that the communication channel uses/accepts only well defined VSCode specific messages related to the UI...
      - collinmanderson 4y ago

louislang 4y ago

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 https://github.com/phylum-dev/cli [2] https://github.com/phylum-dev/birdcage https://github.com/phylum-dev/birdcage

comboy 4y ago
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?
- louislang 4y ago
  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.
coffeeblack 4y ago
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?
- louislang 4y ago
  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.

koolba 4y ago

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

kibwen 4y ago

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.

namaria 4y ago
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.
- 0cf8612b2e1e 4y ago
  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.
  - namaria 4y ago
    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.
  - fbhabbed 4y ago
    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.
- 4y ago

secondcoming 4y ago

This is the way.

ashishbijlani 4y ago

Packj sandbox [1] offers "safe installation" of PyPI/NPM/Rubygems packages. 1. https://github.com/ossillate-inc/packj/blob/main/packj/sandbox/README.md https://github.com/ossillate-inc/packj/blob/main/packj/sandb... It DOES NOT require a VM/Container; uses strace. 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 a year now.

collinmanderson 4y ago
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.

weinzierl 4y ago

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.

Bright_Machine 4y ago

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.

throwaway290 4y ago

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