-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Looking through the code it does look like permissions given to a module roll-down to it's child dependencies. This is a terrible idea, as it will fail your security test for any non trivial node module.
Example: Say I have a module which allows me to easily make https requests. By it's very nature it requires access to https. But it has a dependency which is used to parse the post-body data. This should have no access to network or fs.
But because the parent has access to network, this dependency will too. Now, if this dependency gets subverted, it will use the parent's permission to do it's malicious tasks.
Ideally permissions should roll-up rather than roll-down. Each module should explicitly list the permissions it requires and all those should be rolled up and presented to the user when installing. Also, there should be some way to lock permissions to a module.
Say, I am a module developer, and my module has depencies on A and B. When I install these, whatever permissions I give them, get locked down. Now when my users install my module, these same permissions get locked down for that dependency. It can never change. This way the onus of verifying correct permissions shifts towards module authors, who would be a tad bit more vigilant than your everyday developer.