Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permission Model adoption from Package Managers #1300

Closed
RafaelGSS opened this issue May 1, 2024 · 4 comments
Closed

Permission Model adoption from Package Managers #1300

RafaelGSS opened this issue May 1, 2024 · 4 comments
Labels

Comments

@RafaelGSS
Copy link
Member

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

@arcanis
Copy link

arcanis commented May 1, 2024

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.

@RafaelGSS
Copy link
Member Author

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

@arcanis
Copy link

arcanis commented May 2, 2024

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.

Copy link
Contributor

github-actions bot commented Aug 1, 2024

This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.

@github-actions github-actions bot added the stale label Aug 1, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants