Node.js Maintainers Threat Model: Access per Group table

RafaelGSS commented 2 months ago

Hi folks, as part of Node.js Security initiative we have created a table of access per group based on available roles under Node.js org. We'd like to get some feedback/review. Feel free to edit the table if you think something is wrong (I can read the history and update our hackmd table).

The idea is to have a table of permissions and then look at the threats each role has and its impact on the nodejs organization.

Access per Group

Levels: (-) none, (r) read, (w) write, (a) admin/owner (inspiration from https://mason.gmu.edu/~montecin/UNIXpermiss.htm)

Additional notes:

While some teams can have access to a resource, like the secrets, they might have different access level internally based on sub-groups.
Some individuals and team have access such write in different GitHub repositories in the org, like Working groups or subteams.

[!NOTE] ¹ - All repositories with code that get published or has some impact on nodejs/core ² - Releasers has access to run CI during CI Embargo (Security Release)

Resource	External people	Contributors - Core/Triagers/WG	Build - Test/Infra/Admin	Admin - TSC/Releasers/Moderation	Security Stewards/Triagers/External	GitHub - Actions/Plugins
HackerOne	-	---	---	aw-	www	--
MITRE	-	---	---	a--	w--	--
private/node-private	-	---	www	aw-	w-w	--
private/security-release	-	---	---	a--	ww-	--
private/secrets	-	---	www	a--	---	--
nodejs/node	r	wrr	rrw	awa	rrr	wr
nodejs/deps¹	r	rrr	rrw	arr	rrr	wr
nodejs/build (GH)	r	rrr	rrw	awa	rrr	wr
nodejs/node-core-utils	r	rrr	rrw	awa	rrr	wr
npm account	-	-	-a-	a--	---	--
Jenkins CI - test	r	ww-	wwa	-w²-	---	ww
Jenkins CI - release	-	---	-ww	-w-	---	--
Infra - test	-	w--	aaa	ww-	-w-	ww
Infra - release	-	---	-ww	-w-	---	--
Build infra	-	---	-a-	---	---	--
Website Infra	-	---	-a-	a--	---	--
Youtube	-	--w	---	a--	---	--
Zoom	r	rrw	---	a--	---	--
1Password	-	--r	---	a--	---	--
Social media accounts	-	---	---	---	---	--
Email (nodejs-sec)	r	rrr	rrr	awr	wrr	rr
Email (io.js aliases)	r	---	-a-	w--	---	--

Repos under nodejs which do not include code, are not covered as they cannot lead to the threats listed. pkgjs.org is excluded as it does not include code/repos that make it into Node.js binaries

RafaelGSS commented 2 months ago

ping @nodejs/build @nodejs/releasers for visibility

richardlau commented 2 months ago

What is the difference between infra/admin in "Build - Test/Infra/Admin"?

richardlau commented 2 months ago

What is the difference between infra/admin in "Build - Test/Infra/Admin"?

Perhaps "Admin" is supposed to encompass the two Jenkins admins groups (one for the test CI and one for the release CI)? But in that case it would only apply to the CI servers (and not the test/release machines themselves or any other resource on the list).

richardlau commented 2 months ago

"Website Infra" needs to be clarified, or probably split. The Build WG in general doesn't have access to the Vercel set up.

richardlau commented 2 months ago

Re. ² - Releasers has access to run CI during CI Embargo (Security Release) the whole "Jenkins CI - test" row is different for CI Embargo (e.g. external and collaborators lose read access during the Embargo (but TSC and security triage retain read access)).

RafaelGSS commented 2 months ago

What is the difference between infra/admin in "Build - Test/Infra/Admin"?

Perhaps "Admin" is supposed to encompass the two Jenkins admins groups (one for the test CI and one for the release CI)? But in that case it would only apply to the CI servers (and not the test/release machines themselves or any other resource on the list).

Yes, that's my understanding. cc: @UlisesGascon

"Website Infra" needs to be clarified, or probably split. The Build WG in general doesn't have access to the Vercel set up.

Right, when we were discussing it we weren't aware of the roles and resources for nodejs.org, so we put Website Infra. Maybe @nodejs/web-infra can help us splitting it.

Re. ² - Releasers has access to run CI during CI Embargo (Security Release) the whole "Jenkins CI - test" row is different for CI Embargo (e.g. external and collaborators lose read access during the Embargo (but TSC and security triage retain read access)).

Would make sense to add an additional row for Embargo CI?

mhdawson commented 2 months ago

What is the difference between infra/admin in "Build - Test/Infra/Admin"?

We actually have

test
infra admins
jenkins admins
release jenkins admin
release admins
github bot admins

I can't quite remember but I think as a simplification we grouped all of the non-infra admins together. It might make more sense to have

test admins (test, github bot admins, test jenkins admins) infra admins release admins (release jenkins, release admins)

which I would shorten to test/release/infra

@richardlau what do you think?

richardlau commented 2 months ago

What is the difference between infra/admin in "Build - Test/Infra/Admin"?

We actually have
* test

* infra admins

* jenkins admins

* release jenkins admin

* release admins

* github bot admins
I can't quite remember but I think as a simplification we grouped all of the non-infra admins together. It might make more sense to have

test admins (test, github bot admins, test jenkins admins) infra admins release admins (release jenkins, release admins)

which I would shorten to test/release/infra

@richardlau what do you think?

If it makes it easier to summarise, sure. But e.g. test, github bot admins, test jenkins admins are three separate groups and being in one of those groups does not imply being in one of the others.

test/release/infra definitely makes more sense than test/infra/admin.

mhdawson commented 2 months ago

@richardlau understood about them being different groups, in a number of cases we've combined to make the table/assessment feasible.

That means that we may estimate the risk. If that leads to risks that are highlighted as the top risk being not quite right we might adjust but if the results are risks that even with the overestimate are acceptable the simplication is worth it and we'll leave as is.

flakey5 commented 2 months ago

@RafaelGSS

Access for Website Teams

Resource	External People	web-infra/nodejs-website	Other teams
nodejs/release-cloudflare-worker¹	r	wr	r
nodejs/api-doc-tooling²	r	ww	r
nodejs/nodejs.org	r	ww	r
Sentry	-	aa	-
Cloudflare Account	-	--³

¹ The release worker isn't deployed yet (nodejs/build#3461) ² Not being used yet (nodejs/node#52343) ³ Some have read access to parts of the Cloudflare account. Members of web-infra can deploy the release-cloudflare-worker via Github actions which writes to the Cloudflare account.

Blank for ones already included in the table above. Omitted archived repositories (nodejs/nodejs.org-archive, nodejs/node.js.org, nodejs/nodejs.dev)

Threats

Can't get the table to format but,

nodejs/release-cloudflare-worker: Malicious use of infrastructure, Malicious links or content in website and/or documentation, Substitution of Node.js binaries¹
nodejs/api-doc-tooling: Malicious links or content in website and/or documentation
nodejs/nodejs.org: Malicious use of infrastructure, Malicious links or content in website and/or documentation, Substitution of Node.js binaries, Malicious code in npm packages published by the project²
Cloudflare: Malicious links or content in website and/or documentation, Substitution of Node.js binaries¹

¹ When the release worker gets deployed ² No packages are being published yet but will be in the future (nodejs/api-docs-tooling#10)

@ovflowd can you comment on access to Vercel?

nodejs / TSC