Permission Model adoption from Package Managers
RafaelGSS opened this issue · comments
Hi folks,
As part of Permission Model initial roadmap (#898), we would like to discuss how Permission Model can be used by package managers to prevent (partially) supply chain attacks, mostly through postinstall scripts.
If you install a package containing a 'postinstall' script that attempts to compromise the filesystem somehow, the permission model can act and prevent it. Considering this is an experimental feature, I suggest having it behind a flag as well when using package managers.
cc: @nodejs/npm @arcanis
How would you envision it being used? Since legitimate postinstall scripts often are about building native packages, they end up executing code in a way that the Node permission model wouldn't apply.
How would you envision it being used? Since legitimate postinstall scripts often are about building native packages, they end up executing code in a way that the Node permission model wouldn't apply.
In case of building native packages, it will be denied, yeah. I was imagining a specific use case where a Node.js script is run. Do you see another use case for this? Either during the package installation or the module usage itself
On the top of my head I don't see a lot of use cases for Node.js-based postinstall scripts - afaik the two categories in the wild are:
- Lazily downloading prebuilt binaries; that's something that's better served with
optionalDependencies, since it integrates with the cache and lockfile. So we don't really want to encourage that. - Print something during install; that's something Yarn doesn't support by default as we don't print messages unless the package completely fails to install.
So limiting the scope of Node.js scripts during postinstall isn't that impactful imo: in most cases users will be better served by disabling the postinstall entirely (if it's an ad), or running it with full permissions (if it's a compiled package).
With that said I think it could be interesting to discuss how to make yarn run secure the processes it starts - while I'm afraid postinstall is kind of an unfortunate evil, I could imagine us setting up a jail in yarn run so that transitive dependencies of your scripts (especially those which don't define a postinstall scripts, and thus have less scrutiny) can't compromise the user.