|
| 1 | +# Security Model Strategy |
| 2 | + |
| 3 | +A clear security model, with features like permissions and policy enforcement, |
| 4 | +is a |
| 5 | +[top technical priority](https://github.com/nodejs/node/blob/master/doc/contributing/technical-priorities.md#permissionspoliciessecurity-model) |
| 6 | +of Node.js. |
| 7 | + |
| 8 | +## High-level approach |
| 9 | + |
| 10 | +* Document the security model |
| 11 | +* Document threat models and current state of the art |
| 12 | +* Support experimentation on features like permissions and policies |
| 13 | +* Add a security component in Node.js certification covering |
| 14 | + the Node.js security model |
| 15 | + |
| 16 | +### Document the security model |
| 17 | + |
| 18 | +The current security model for Node.js is not yet well documented. |
| 19 | +At a high level it is: |
| 20 | + |
| 21 | +* Node.js does not provide a sandbox, both the JavaScript and |
| 22 | + native code which is run is trusted to not be malicious. |
| 23 | +* The project works to help code running on top of Node.js to avoid |
| 24 | + making mistakes, but not doing so is not considered a |
| 25 | + vulnerability in Node.js. Just because you can build something |
| 26 | + vulnerable with the APIs does not mean there is a vulnerability |
| 27 | + in Node.js itself. |
| 28 | + |
| 29 | +The project has a goal to better document the security model |
| 30 | +and this section will be expanded when that happens. |
| 31 | + |
| 32 | +Once the security model is documented the project will work |
| 33 | +to add a security component in Node.js certification covering |
| 34 | +the Node.js security model. |
| 35 | + |
| 36 | +### Document threat models and current state of the art |
| 37 | + |
| 38 | +Node.js is used in several different use cases and the |
| 39 | +threats may be different in each use case. The project |
| 40 | +should document the threat models and use that to |
| 41 | +help define the security model in the context of each |
| 42 | +of these use cases. |
| 43 | + |
| 44 | +This section will be expanded as the use case/threat |
| 45 | +models are defined. The initial list includes: |
| 46 | + |
| 47 | +* Server |
| 48 | +* Desktop application |
| 49 | +* Cli |
| 50 | +* Single executable application |
| 51 | +* CI/CD pipeline components |
| 52 | + |
| 53 | +### Support experimentation on features like permissions and policies |
| 54 | + |
| 55 | +The project is not currently planning to provide supported |
| 56 | +sandbox functionality, but wants to support experimentation on |
| 57 | +related features like policies and permission enforcement. |
| 58 | + |
| 59 | +Features in this category should: |
| 60 | + |
| 61 | +* be opt-in, and additional overhead when not enabled must be low |
| 62 | +* limit change in core to just what is needed to enable experimentation |
| 63 | + |
| 64 | +## Current implementation and assets |
| 65 | + |
| 66 | +Node.js has an experimental implementation of |
| 67 | +[policies](https://nodejs.org/docs/latest/api/policy.html#policies). |
| 68 | + |
| 69 | +The core implementation is in: |
| 70 | + |
| 71 | +* [`lib/internal/process/policy.js`](https://github.com/nodejs/node/blob/HEAD/lib/internal/process/policy.js) |
| 72 | +* [`lib/internal/policy`](https://github.com/nodejs/node/blob/HEAD/lib/internal/policy) |
| 73 | + |
| 74 | +along with integration into the CJS and ESM loaders in: |
| 75 | + |
| 76 | +* [`lib/internal/modules/esm`](https://github.com/nodejs/node/blob/HEAD/lib/internal/modules/esm) |
| 77 | +* [`lib/internal/modules/cjs`](https://github.com/nodejs/node/blob/HEAD/lib/internal/modules/cjs) |
0 commit comments