Permission Model - Roadmap

As discussed earlier in nodejs/node#44004 and #791, the purpose of this issue is to establish a comprehensive roadmap for the Permission Model. I will be proceeding with the following list of action items, and in cases where further discussion is necessary, I will initiate a separate issue for each item.

Permission Model adoption on package managers (Permission Model adoption from Package Managers #1300)
Support path.resolve in C++ side to avoid possiblyTransformPath lib,src,permission: port path.resolve to C++ node#50758
- Support relative paths lib,src,permission: port path.resolve to C++ node#50758
~~Read permissions from a config file (policy.json)~~ - Load permission settings from config files #1074
Throw access denied asynchronously for async APIs. (src,permission: throw async errors on async APIs node#52730)
```
fs.readFile('restricted-file.md', (error) => {
  // error is ERR_ACCESS_DENIED
})
```
Allow Addons src,permission: add --allow-addon flag node#51183

New permissions

net

cc: @nodejs/tsc for awareness

Sorry if this is intrusive and not productive, I didn't see a rationale for choosing a new file (permissions.json) vs an existing file with a new property (package.json:permissions), is there one available somewhere for me to read?

@BrunoBernardino

This is a good discussion, @BrunoBernardino. We'll certainly evaluate that when working on this implementation. Likely, the outcome will be from the discussion with package managers.

Is there any reason to separate policy integrity/redirects from permissions, would be ideal if they could share the same file. Particularly if eventual possibility of more granular per resource (URL) configuration.

Is there any reason to separate policy integrity/redirects from permissions, would be ideal if they could share the same file. Particularly if eventual possibility of more granular per resource (URL) configuration.

My only concern is the fact policies are experimental, so the permissions will be blocked to get out of the experimental until policies are stable. Other than that, sounds good to me.

My only concern is the fact policies are experimental, so the permissions will be blocked to get out of the experimental until policies are stable. Other than that, sounds good to me.

One could argue that it's another reason for using policies, so both can graduate to stable faster ;)

Using the same file isn't really related to blocking advancement also name of the file isn't important ( can already use policies with a file called permissions.json)

…

On Fri, Mar 3, 2023, 6:17 AM Antoine du Hamel ***@***.***> wrote: My only concern is the fact policies are experimental, so the permissions will be blocked to get out of the experimental until policies are stable. Other than that, sounds good to me. One could argue that it's another reason for using policies, so both can graduate to stable faster ;) — Reply to this email directly, view it on GitHub <#898 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJI5W6WL3VK4MGJDJBO3W2HOMBANCNFSM6AAAAAAVM2H4QQ> . You are receiving this because you commented.Message ID: ***@***.***>

Just gave this a run through, very excited to see this going through. Just a few notes from an outsider / end user. I'm not up to speed on everything so, please take with a grain of salt!

a separate file for permissions will be groaned at. Everyone has config fatigue - putting it in package.json is ideal for me.
relative paths via the CLI - I'm not sure if there is a technical hurdle here, but this would be really nice, especially for all the random npx scripts people have you running.
Prompting for access would be great - similar to how Deno does it. this way you can run a script, and be prompted to see which files need to be read/written etc..

The first 2 items are already on the roadmap. The third one:

Prompting for access would be great - similar to how Deno does it. this way you can run a script, and be prompted to see which files need to be read/written etc.

Is tricky. It can open many vectors of attack and I'm not sure about how useful is it for production apps. I feel like I rather prefer to receive an exception, close my app and adjust the permissions according to the expected paths than not have it explicitly and do it by a prompt. We can definitely discuss it at Security WG. cc: @nodejs/security-wg

I'd just note, per the config problem, it most likely should not be authoritative from a given package.json but likely could be generated from an aggregation of multiple package.json files automatically into a different file is the current thoughts. This gets very complex however, as things like npm run lint likely has different permissions desired than npm run start and would heavily clutter package.json unless making everything run at same permissions level. Certainly open to discuss but would be good to understand the desires of keeping it inline, if it is meant to be configuration or authoritative.

Background

The program i'm running is using a fake malicious NPM package (for security research).

See example attack flow:

Attacker produce the package
- This package is made to look like an Express server util
Attacker publishes the package to npmjs.com
The victim downloads & installs the package in their NodeJS application (unknowing of the malicious aspect)
The package is used in the victims application code (since they need the legitimate part of the package)
The victim starts their application locally
The attacker gets reports sent from the victims computer with the follwing info:
- Local tunnel URL (so the attacker can reach a web ui where they can send commands to the victims computer)
- Victims public ip (used to work around security for Local tunnel, as it's required - similar to a password)
The attacker can now run any command that is allowed by Node (usually root access, as proven by tests)
- See examples below what can be run (for example)

The intention is to see how Node permission system can protect a potential victim against these types of attacks 3rd party package attacks. Without the permission system in place, a Node program running this dependency WILL be compromised (tested on multiple computers an deployed environment etc).

For code reference see here:

https://github.com/KennyLindahl/malicious-npm-package

How my program was run

Node version: v20.5.0

node --experimental-permission --allow-fs-read=$(realpath ./index.js),$(realpath ./node_modules) index.js

Cases

HTTP requests

When run, the malicious package could still get the victims IP and send it to the attacker (this is expected since there is no URL whitelist)

Question

So my question is if there will be HTTP request block + whitelisting of URLs?

Spawn

My fake malicious NPM package tried to start a local tunnel via spawn, and this was blocked which is good.
However this was never logged in in the Node program, it was only captured and delivered as text to the attackers computer (see code below).

This is what the code looked like in the fake malicious NPM package

function spawnHelper(command, args, onData) {
  return new Promise((resolve, reject) => {
    try {
      const commandResponse = spawn(command, args);

      commandResponse.stdout.on("data", (data) => {
        onData(data.toString());
      });

      commandResponse.stderr.on("data", (data) => {
        onData(data.toString());
      });

      commandResponse.on("error", (error) => {
        onData(error.toString());
        reject(error);
      });
    } catch (error) {
      onData(error.toString());
    }
  });
}

See reference here: https://github.com/KennyLindahl/malicious-npm-package/blob/master/malicious.js#L82

And executed via:

await spawnHelper(localTunnelBinPath, ["--port", PORT], report);

Question

Is this expected? In a real scenario i would never know what the attacker has tried to do etc, which is not ideal.
Ideally i should be able to:

See any possible permission breaches in my application log
Possibility to listen to events of permission breaches (so i can send email to my team etc)

Thanks

Read permissions from a config file (policy.json)

Hi I'll be working on this.

@KennyLindahl

@KennyLindahl

So my question is if there will be HTTP request block + whitelisting of URLs?

Currently, the Permission Model does not enforce NET permissions (HTTP, TCP, UDP and so on). This issue is about the roadmap of this feature, net certainly is on the road (we haven't designed how it gonna work, but we should be looking into it -- note: it doesn't guarantee we'll add it, but we'll, for sure, try)

However this was never logged in in the Node program, it was only captured and delivered as text to the attackers computer (see code below).

That's expected, but we can improve it for sure. We might want to add diagnostic_channel whenever permission is denied. I'll add it to the roadmap so we can discuss it further.

What about this idea: add a CLI flag to make the process abort (so it cannot be caught by the caller) whenever permission is denied?

If doing so, what exactly is the goal? If this is about security auditability, what should happen if the application uses process.permission.has() to first check whether a subsequent call would result in a permission error?

@legrego

See nodejs/node#51183 @legrego

@RafaelGSS

Thank you, @RafaelGSS!

lib,src,permission: port path.resolve to C++

With nodejs/node#52730 I think it's time to discuss it Permission Model usage with package managers.

src,permission: throw async errors on async APIs

Closing this as completed. A second iteration of Permission Model will be created shortly.

src,permission: throw async errors on async APIs

Navigation Menu

Repository navigation

Permission Model - Roadmap #898

New permissions

Background

How my program was run

Cases

HTTP requests

Question

Spawn

Question

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Permission Model - Roadmap #898

Description

New permissions

Activity

BrunoBernardino commented on Mar 2, 2023

RafaelGSS commented on Mar 2, 2023

bmeck commented on Mar 2, 2023

RafaelGSS commented on Mar 3, 2023

aduh95 commented on Mar 3, 2023

bmeck commented on Mar 3, 2023

wesbos commented on Apr 18, 2023

RafaelGSS commented on Apr 18, 2023

bmeck commented on Apr 19, 2023

KennyLindahl commented on Aug 10, 2023

Background

How my program was run

Cases

HTTP requests

Question

Spawn

Question

Ceres6 commented on Aug 14, 2023

RafaelGSS commented on Aug 14, 2023

targos commented on Aug 15, 2023

tniessen commented on Aug 15, 2023

6 remaining items

RafaelGSS commented on Dec 16, 2023

legrego commented on Dec 17, 2023

RafaelGSS commented on Apr 29, 2024

RafaelGSS commented on May 1, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions