Skip to content

Commit

Permalink
doc: initial version of security-model-strategy.md
Browse files Browse the repository at this point in the history
Added initial strategy based on discussion in
the next-10 mini-summit -
https://github.com/nodejs/next-10/blob/main/meetings/summit-apr-2022.md

Signed-off-by: Michael Dawson <[email protected]>

PR-URL: #42709
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: Gireesh Punathil <[email protected]>
Reviewed-By: Darshan Sen <[email protected]>
Reviewed-By: Akhil Marsonya <[email protected]>
Reviewed-By: Rafael Gonzaga <[email protected]>
Reviewed-By: Bryan English <[email protected]>
  • Loading branch information
mhdawson authored and targos committed May 2, 2022
1 parent 37ca110 commit e15d22c
Showing 1 changed file with 77 additions and 0 deletions.
77 changes: 77 additions & 0 deletions doc/contributing/security-model-strategy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# Security Model Strategy

A clear security model, with features like permissions and policy enforcement,
is a
[top technical priority](https://github.com/nodejs/node/blob/master/doc/contributing/technical-priorities.md#permissionspoliciessecurity-model)
of Node.js.

## High-level approach

* Document the security model
* Document threat models and current state of the art
* Support experimentation on features like permissions and policies
* Add a security component in Node.js certification covering
the Node.js security model

### Document the security model

The current security model for Node.js is not yet well documented.
At a high level it is:

* Node.js does not provide a sandbox, both the JavaScript and
native code which is run is trusted to not be malicious.
* The project works to help code running on top of Node.js to avoid
making mistakes, but not doing so is not considered a
vulnerability in Node.js. Just because you can build something
vulnerable with the APIs does not mean there is a vulnerability
in Node.js itself.

The project has a goal to better document the security model
and this section will be expanded when that happens.

Once the security model is documented the project will work
to add a security component in Node.js certification covering
the Node.js security model.

### Document threat models and current state of the art

Node.js is used in several different use cases and the
threats may be different in each use case. The project
should document the threat models and use that to
help define the security model in the context of each
of these use cases.

This section will be expanded as the use case/threat
models are defined. The initial list includes:

* Server
* Desktop application
* Cli
* Single executable application
* CI/CD pipeline components

### Support experimentation on features like permissions and policies

The project is not currently planning to provide supported
sandbox functionality, but wants to support experimentation on
related features like policies and permission enforcement.

Features in this category should:

* be opt-in, and additional overhead when not enabled must be low
* limit change in core to just what is needed to enable experimentation

## Current implementation and assets

Node.js has an experimental implementation of
[policies](https://nodejs.org/docs/latest/api/policy.html#policies).

The core implementation is in:

* [`lib/internal/process/policy.js`](https://github.com/nodejs/node/blob/HEAD/lib/internal/process/policy.js)
* [`lib/internal/policy`](https://github.com/nodejs/node/blob/HEAD/lib/internal/policy)

along with integration into the CJS and ESM loaders in:

* [`lib/internal/modules/esm`](https://github.com/nodejs/node/blob/HEAD/lib/internal/modules/esm)
* [`lib/internal/modules/cjs`](https://github.com/nodejs/node/blob/HEAD/lib/internal/modules/cjs)

0 comments on commit e15d22c

Please sign in to comment.