Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Other lessons could be taken from this. For example:

When you build a package management system that has user-configurable exec scripts, run them in a secure sandbox/container by default. If you provide an override, require a user to approve it and show them the command that will be run on their system.

If npm package.json scripts only ran in a lightweight linux container with no access to the filesystem, the mere act of doing an `npm install` could not pwn your box.

Another possible takeaway would be that everyone should use Qubes, or some similar project, such that the machine where they use npm doesn't contain any important credentials, and then all publishing is done in CI or in another qubes vm dedicated to the purpose which publishes a shrinkwrapped artifact rather than installing locally.



You don't even need containers on linux. If SELinux was more accessible, this would be a very cool use case.

You could set the security context of your NPM access credentials to something other than unconfined and ensure that only processes with a specific security label can access files tagged with that security context. These security labels in term are kernel controlled. So at that point, a malicious install script needs to escalate to root in order to steal your credentials.

It's kinda sad how such a powerful and rather simple tool is so hard to use.


While it would be nice to be able to run `npm install` fearlessly, how much would it truly help? In almost all cases, the code downloaded from npm will be executed non-sandboxed anyways; that's probably the reason you installed the package after all.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: