7 ms·

Nice deflection of the real madness here that a compromised npm package gets to read stuff in your user directory.

tptacek 8y ago
Yes, that's what this was. An elaborate attempt to shield npm from scrutiny. We know where our bread is buttered.
annabellish 8y ago
I mean, of course it does. Most people run their development environments as their own user, and most package management systems have post-install script support. Installing random software from the internet is problematic.
- vemv 8y ago
  I'd be interested in running my dev environment with a dedicated user account -with no access to the main account's personal files, credentials, etc-, do you know of any guides for doing so? (I could just give it a shot, but I reckon there will be gotchas)
  - andreareina 8y ago
    What I do is use a VM as my development environment, managed by Vagrant. Any dependencies stay on the VM image.
  - angry_octet 8y ago
    What platform? GUI or shell? Docker/LXD or a dev VM lets you access both simultaneously. Or create a separate user, but not as secure or convenient.
    - vemv 8y ago
      macOS. Not much interested in VMs, for efficiency. Yeah I was playing with a separate user account, could get some basics working but I wonder how far could I get with that. What are the bigger security risks for that approach? Assuming constrained file permissions, and that no secrets are in ENV (https://gist.github.com/telent/9742059 https://gist.github.com/telent/9742059 )
      - angry_octet 8y ago
        A normal user has full access to the kernel API. Always kernel info leaks, occasional easy exploits. On macos you can use Apple's native sandboxing. See for example http://mybyways.com/blog/creating-a-macos-sandbox-to-run-kodi http://mybyways.com/blog/creating-a-macos-sandbox-to-run-kod...
lvh 8y ago
I explicitly raise that point in the post. Hardening one aspect of something does not preclude you from hardening others. Also: if I was trying to somehow draw attention away from that fact, I probably wouldn't write a blog post that mentions it 2 weeks later.
AgentME 8y ago
Is that not true of most dependency manager + build systems? To focus on maven as an example, maybe it doesn't have a post-install hook for dependencies it downloads, but any build or test dependencies downloaded while building a project are going to be immediately executed unsandboxed. At least npm has the package-lock.json feature that lets you lock down the entire dependency graph. If the package-lock.json was created with a safe set of dependencies, then any dependencies compromised in the future won't affect you (because already released versions can't be modified). Maven and gradle both seem to entirely lack a comparable feature as far as I know; if they do have that functionality as an obscure feature or plugin, then I still criticize them for not making it more prominent. (Npm generates and uses package-lock.json by default!)
- andreareina 8y ago
  Technically, other systems are vulnerable to the same. In practice, there's something about the node/js ecosystem that encourages the proliferation of dependencies, increasing the attack surface.

Yes, that's what this was. An elaborate attempt to shield npm from scrutiny. We know where our bread is buttered.

I mean, of course it does. Most people run their development environments as their own user, and most package management systems have post-install script support. Installing random software from the internet is problematic.

vemv 8y ago
I'd be interested in running my dev environment with a dedicated user account -with no access to the main account's personal files, credentials, etc-, do you know of any guides for doing so? (I could just give it a shot, but I reckon there will be gotchas)
- andreareina 8y ago
  What I do is use a VM as my development environment, managed by Vagrant. Any dependencies stay on the VM image.
- angry_octet 8y ago
  What platform? GUI or shell? Docker/LXD or a dev VM lets you access both simultaneously. Or create a separate user, but not as secure or convenient.
  - vemv 8y ago
    macOS. Not much interested in VMs, for efficiency. Yeah I was playing with a separate user account, could get some basics working but I wonder how far could I get with that. What are the bigger security risks for that approach? Assuming constrained file permissions, and that no secrets are in ENV (https://gist.github.com/telent/9742059 https://gist.github.com/telent/9742059 )
    - angry_octet 8y ago
      A normal user has full access to the kernel API. Always kernel info leaks, occasional easy exploits. On macos you can use Apple's native sandboxing. See for example http://mybyways.com/blog/creating-a-macos-sandbox-to-run-kodi http://mybyways.com/blog/creating-a-macos-sandbox-to-run-kod...

lvh 8y ago

I explicitly raise that point in the post. Hardening one aspect of something does not preclude you from hardening others. Also: if I was trying to somehow draw attention away from that fact, I probably wouldn't write a blog post that mentions it 2 weeks later.

AgentME 8y ago

Is that not true of most dependency manager + build systems? To focus on maven as an example, maybe it doesn't have a post-install hook for dependencies it downloads, but any build or test dependencies downloaded while building a project are going to be immediately executed unsandboxed. At least npm has the package-lock.json feature that lets you lock down the entire dependency graph. If the package-lock.json was created with a safe set of dependencies, then any dependencies compromised in the future won't affect you (because already released versions can't be modified). Maven and gradle both seem to entirely lack a comparable feature as far as I know; if they do have that functionality as an obscure feature or plugin, then I still criticize them for not making it more prominent. (Npm generates and uses package-lock.json by default!)

andreareina 8y ago
Technically, other systems are vulnerable to the same. In practice, there's something about the node/js ecosystem that encourages the proliferation of dependencies, increasing the attack surface.