Skip to content

Permission Model adoption from Package Managers #1300

Closed as not planned
Closed as not planned

Description

@RafaelGSS

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

Activity

  1. arcanis commented on May 1, 2024

    @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.

  2. RafaelGSS commented on May 1, 2024

    @RafaelGSS
    MemberAuthor

    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

  3. arcanis commented on May 2, 2024

    @arcanis

    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.

  4. github-actions commented on Aug 1, 2024

    @github-actions
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions