[Security] API access permissions for NPM modules #14

This feature would involve changes in both the Node.js and NPM projects but I thought that this repository would be an appropriate place to discuss it.

The idea is to basically mock the access permission feature that Android and iOS SDKs have.
Not unlike most OAuth API's, NPM modules could have a "permissions" field in their package.json file that describes a scope of native Node.js modules and type of access (read, write, ...) needed.
e:g:

{
    // usual package.json fields
    // ...
    "permissions": {
        "fs": "rw",     // read + write flag
        "http": "r"         // read flag
    }
}

Naturally, a NPM package would need a scope that consists of all it's dependencies's scopes (recursively calculated at NPM install time) plus it's own.

Installing modules in this mode would be a little different than usual because NPM would have to ask your permission for each top-level module.

Additionally, there could be an option where developers could specify global permissions for every NPM module.
e:g:

{
    // usual package.json fields
    // ...
    "dependencies": {
        "test": "1.0.0"
    },
    "globalPermissions": {
        "filesytem": "r"    // read flag
    }
}

In the following package.json file, if the test module would need a "filesytem": "rw" permission, you would get a conflict.
Conflict resolution could be inspired by Bower's version conflict resolution implementation.

Scopes could include: filesystem, shell, child process, http and tcp (or a network scope that would combine both).

Flags could include: r (read), w (write), o (overriding native methods).

By briefly reading the implementation of the require() method, I saw that a Node.js VM was created with the parent's context.
I'm not a core developer so obviously this is just pure speculation on my part, but maybe this feature could be implemented by limiting the VM's context to the subset of native modules specified in the package.json file ?
Would that be sufficient ?

Some tricky parts:

• It might be more difficult to limit NPM modules with C/C++ bindings.
• If you have access to the shell scope you can more or less emulate any other access scope.

You actually have a kind of implied hierarchy to access permissions.

Obviously Node.js wasn't designed with this feature in mind but I think that this could really help NPM and Node.js protect users against malicious modules or hacked developer accounts in an effective way.

It's also a good argument to convince larger companies that hesitated to use Node.js before due to how NPM modules work and the lack of control they have over them (besides versions).

What do you guys think ?