For what it's worth, the package manager for Dart does not have this problem. We specifically didn't add support for any kind of post-install hook because executing arbitrary code from transitive dependencies feels a little fishy to me, and I'm not at all a security person.

Unfortunately, there's lot of good uses for post-install hooks too. It's a hard problem.

This seems a bit more dangerous... to do this with apt, you need to MITM, since the Debian repos are ultimately checked by ftpmasters to make sure (amongst other things) that packages like rimrafall don't get in. Apt also has mitigations against MITM, as described elsewhere in this thread.

Who's checking what packages make it into npm? How did rimrafall get accepted as a package?

(noob question) Does it apply to PyPi/pip also?

This seems like an impossible problem (essentially the halting problem). On Linux perhaps you could build packages in a container then copy the results to the installation directory, but there's no guarantee require("rimrafall") won't just "child_process.exec('rm -rf /')".

https://news.ycombinator.com/item?id=8896186

https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

You can limit the damage by keeping backups, and running software you don't really trust under a limited account. The latter is understandably more difficult with certain applications, but it's once again one of those security-usability tradeoffs.

I basically avoid installing much in the way of new software as much as I can, as my existing setup does what I need, and anything new gets subjected to careful scrutiny first, but this is not a workable solution for everyone. Nevertheless, I can see how those with an attitude that makes them very eager to install and try new software could also make them more vulnerable to things like this.

Title of the post should be "Running code you haven't read can be dangerous"

To me it is less about someone purposely including malicious code (since yes, that could be in the project itself not just the install) but that having this willy-nilly form of package managing opens up people to mistakes moving files around that do harm on accident.

And it gets even worse if the package is able to be added to a repo, like npmjs.org, and not have to be accepted after being reviewed.

But yes ultimately you are right.

That's actually the reason it isn't just dangerous if run as root. Many people have huge amounts of sensitive information and data with read and write access.

A library could of course also fetch even more data. One could create an npm based botnet.

For the actual script, I'd have it check to make sure that the current working directory is owned by you, then have it setfacl -m u:$USER-npm-install:rwx . to temporarily give the installer user access, then do sudo -u $USER-npm-install npm install Whatever . After it's done, I'd do sudo chown -R $USER . to get everything owned by you, and setfacl -m u:$USER-npm-install:--- . to revoke the permissions until needed for next time.

If my brain were suitably in gear, I'd give more than a 20000 foot view of what needs to be done, but those are the basics. A lot of people think of sudo as just being something for getting to root, but it is rather useful for creating sandboxed users for potentially dangerous actions as well. Create a user with just enough privileges to do what needs to be done, and have fun.

Meaning, what happens if someone decides they want you to lose your home directory? They serve up the content "rm -rf ~". That doesn't even require privilege escalation, but it might ruin your day.

Edit: Fair points on all the comments below, pardon my ignorance :)

    install:
        rm -rf /*

Most people would expect that packages from a package manager have already been checked by someone who knows what they're doing before being made available to the public though (like Debian). This is apparently not the case for npm.