4 ms·

Show HN: NodeSecurity – The easiest way to control what NPM modules can access

6 points by matthayward1997 8y ago

ollerac 8y ago
This is a really good idea. A couple questions: • What happens if a package tries to access a core lib it doesn't have permission to? Is what happens different in development and production? • Is there a way for packages to specify which core modules they need to have access to and why? • If a dependency has another dependency that's given access to `fs`, for example, but the top-level dependency doesn't have this access -- can the top level dependency use `fs` through its dependency? • Have you reached out to NPM?
- bgdam 8y ago
  > • If a dependency has another dependency that's given access to `fs`, for example, but the top-level dependency doesn't have this access -- can the top level dependency use `fs` through its dependency? I'm very interested to know the answer to this too. In addition, I'd also like to know, if a dependency A, which itself depends on B which requires permission 'os' (not required by A), does this requirement roll up to A? Also, does giving A certain permissions automatically give them to all the dependencies of A? I actually considered building something similar, but then I knew, I'd never be able to manually keep track of permissions every time I'm adding or removing a dependency. Ideally this would be integrated with package managers, or maybe Node itself. Something like a 'permissions' field in package.json, which is read by the installer, and while installing the user gets prompted. The permissions given by the user then get saved in a lockfile, which gets committed for promptless installs in future. Edit: 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. I'm opening an issue on the Github project page so we can continue this discussion.
- matthayward1997 8y ago
  Thanks! - At the moment if a package tries to access a core lib it doesn't have permission to it will throw an exception. This behaviour is currently the same on both development and production. - There currently isn't a way for packages to specify which core modules they need access to. This is a long term goal and ideally we'd integrate something into npm itself to verify these and any changes to these permissions that occur. - At the moment it works on a top down permission propagation. So if a parent module has access to 'fs' for example, so will all of its dependencies. I'm looking to change this behaviour so this is no longer default for reasons outlined by others. - Haven't reached out NPM just yet, but it's on the todo list.

This is a really good idea. A couple questions: • What happens if a package tries to access a core lib it doesn't have permission to? Is what happens different in development and production? • Is there a way for packages to specify which core modules they need to have access to and why? • If a dependency has another dependency that's given access to `fs`, for example, but the top-level dependency doesn't have this access -- can the top level dependency use `fs` through its dependency? • Have you reached out to NPM?

bgdam 8y ago
> • If a dependency has another dependency that's given access to `fs`, for example, but the top-level dependency doesn't have this access -- can the top level dependency use `fs` through its dependency? I'm very interested to know the answer to this too. In addition, I'd also like to know, if a dependency A, which itself depends on B which requires permission 'os' (not required by A), does this requirement roll up to A? Also, does giving A certain permissions automatically give them to all the dependencies of A? I actually considered building something similar, but then I knew, I'd never be able to manually keep track of permissions every time I'm adding or removing a dependency. Ideally this would be integrated with package managers, or maybe Node itself. Something like a 'permissions' field in package.json, which is read by the installer, and while installing the user gets prompted. The permissions given by the user then get saved in a lockfile, which gets committed for promptless installs in future. Edit: 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. I'm opening an issue on the Github project page so we can continue this discussion.
matthayward1997 8y ago
Thanks! - At the moment if a package tries to access a core lib it doesn't have permission to it will throw an exception. This behaviour is currently the same on both development and production. - There currently isn't a way for packages to specify which core modules they need access to. This is a long term goal and ideally we'd integrate something into npm itself to verify these and any changes to these permissions that occur. - At the moment it works on a top down permission propagation. So if a parent module has access to 'fs' for example, so will all of its dependencies. I'm looking to change this behaviour so this is no longer default for reasons outlined by others. - Haven't reached out NPM just yet, but it's on the todo list.