matthaywardwebdesign
Permissions should not roll down to sub dependencies
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.
Thanks @asleepysamurai for your detailed analysis! Very much appreciated 👍
I'm going to go ahead and implement a change, that will remove the permissions rolling down to sub dependencies as default behaviour, with an option to enable it for those who want it.
Whilst I do agree that the ideal approach to this problem is, as you mentioned, for each module to list the permissions it requires, the reason I didn't attempt to implement this originally is that this would require effectively 100% buy in from the community to work as intended. Every module would have to agree on a format to specify these permissions, and whilst it's my goal, I do feel the team at npm probably have better chances to make this happen.
I've got a couple of thoughts on ways to solve the problem of having to update every module, largely based around code analysis, but would love to hear any suggestions if you've got them!
