doc: initial version of security-model-strategy.md

[mhdawson]

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]

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[mhdawson]

@mscdex thanks for the fixes.

[mcollina]

lgtm

[gireeshpunathil]

sorry for asking it here, but I missed almost all conversations in the summit (though I joined the call, I was distracted).

Node.js has no sandbox and assumes everything as trusted code - Would this mean that Node.js security model boils down to i) vm security (ensuring integrity of vm functions are protected) ii) API security (Node.js API functions are not tampered/manipulated/bypassed), iii) overall application level security is a function of its operating space (server, desktop etc.) and how external code modules are interacting with the application and the Node.js APIs ?

• if yes, does it make sense to state that as the prevailing Node.js security model
• if no, bringing little more clarity on what is considered a Node.js vulnerability

IMO, this will help security triaging process (to quickly decide what is in scope and what is not)

[RaisinTen]

i) vm security (ensuring integrity of vm functions are protected)

I don't think vm imposes any kind of security mechanism -

node/doc/api/vm.md

Lines 14 to 15 in 45162bf

	<strong class="critical">The `vm` module is not a security
	mechanism. Do not use it to run untrusted code.</strong>

. Could you please elaborate on what you mean by protecting the integrity of the vm functions? Something like adding primordials or something else?

[gireeshpunathil]

Could you please elaborate on what you mean by protecting the integrity of the vm functions? Something like adding primordials or something else?

ok, what I mean is: any code - trusted or untrusted, should not be able to modify vm's attributes and behaviours other than through its exported interfaces.

[mhdawson]

ok, what I mean is: any code - trusted or untrusted, should not be able to modify vm's attributes and behaviors other than through its exported interfaces.

I don't quite follow. I think our current model is that all code is trusted there is no concept of untrusted code.

EDIT: To elaborate, if code that you run does something whether through the documented APIs or otherwise, it being able to do that is not a vulnerability in Node.js. You asked that the code be run, and we currently don't promise to protect the environment from the code that you ask to be run.

[mhdawson]

Done

[mhdawson]

@gireeshpunathil, @RaisinTen I agree that documenting what is/is not considered a vulnerability is a good goal, but I think that will take more work discussion so should go into a follow on PR once we have had more conversations to agree what the security model should include (versus the high level that I tried to capture in this initial PR)

[mhdawson]

@gireeshpunathil, @RaisinTen are you ok with this landing in it's current state or do you think we need to flesh out the security model in more detail first?

[mcollina]

lgtm

[RaisinTen]

I'm okay with landing this in its current state. Here are some optional nits.

[gireeshpunathil]

@gireeshpunathil, @RaisinTen are you ok with this landing in it's current state or do you think we need to flesh out the security model in more detail first?

I am ok to land this in its current form. (already approved)

[RafaelGSS]

LGTM.

[mhdawson]

Landed in 17826f5