Runtime Permission Dropping (`process.permission.drop()`

[mcollina]

What is the problem this feature will solve?

The current Permission Model (--allow-fs-read, --allow-fs-write, --allow-child-process, --allow-worker, --experimental-permission) is all-or-nothing at startup. You declare the full set of permissions when launching the process, and they remain fixed for its entire lifetime.

This makes it impossible to implement a common and well-established security pattern: start with the permissions you need for initialization, then drop the ones you no longer need before entering the main event loop.

Real-world Node.js applications routinely need broad permissions at startup (reading config files, loading TLS certificates, binding to privileged ports, spawning setup workers) but then operate in a much narrower scope for the rest of their lifetime. Today, there is no way to tighten the permission boundary after initialization.

What is the feature you are proposing to solve the problem?

const fs = require('node:fs');
 
// Startup: read config and certs (needs broad fs read)
const config = JSON.parse(fs.readFileSync('/etc/myapp/config.json', 'utf8'));
const cert = fs.readFileSync(config.tlsCertPath);
const key = fs.readFileSync(config.tlsKeyPath);
 
// Drop permissions we no longer need
process.permission.drop('fs.read', '/etc/myapp');
process.permission.drop('child');
process.permission.drop('worker');
 
// From here on, the process can no longer read /etc/myapp,
// spawn child processes, or create workers.
// Any attempt to do so throws ERR_ACCESS_DENIED.

A drop() call removes the specified permission from the internal allow-list. It cannot be reversed through process.permission or any other Node.js API. This narrows the set of resources reachable through standard Node.js APIs (fs, child_process, net, etc.), which is where path traversal and similar attacks operate.

As with the rest of the Permission Model, drop() is not a hard process-level security boundary. It does not protect against malicious code with arbitrary V8 access that bypasses Node.js APIs entirely (see Security model).

What alternatives have you considered?

No response

[mcollina]

cc @nodejs/security-wg

[absidue]

What should happen to resources that are still open/running when a permission is dropped? Should file handles be closed, workers and child processes terminated automatically when drop is called? Native addons would be more complicated to unload, because as far as I understand Node.js doesn't currently have a way of doing that.

[ChALkeR]

The idea is great, and I'm in favor

This should be noted though that the "drop permissions" mental model is in somewhat contradiction with the security model which assumes running trusted code only

Which is not theoretical: it leads us to a point that (A) js being able to write to raw process memory not a security issue per model (B) and some in-process protection mechanisms are considered security features

I.e. this is unlikely to be robust against malicious JS:

A drop() call is irreversible within the current thread. Once a permission is dropped, it cannot be re-acquired.

A better documentation on this should signal that those are not hard process-level security mechanisms and can't be expected to be not bypassable with js code executed after the "drop"

[mcollina]

What should happen to resources that are still open/running when a permission is dropped? Should file handles be closed, workers and child processes terminated automatically when drop is called? Native addons would be more complicated to unload, because as far as I understand Node.js doesn't currently have a way of doing that.

Everything that has happened before the drop would stay. That's the goal of the feature.

[absidue]

Everything that has happened before the drop would stay. That's the goal of the feature.

In that case if/when permission dropping is implemented it should be clearly documented that dropping permissions at runtime should not be treated as equal to never granting them in the first place, so that people are aware that they still need to be careful what permissions they grant and what they do before dropping a permission, to avoid malicious actors piggybacking on things that were left open/running. As one might naively assume that revoking a permission would also revoke access to all existing resources that were previously granted through that permission, which is how other permission systems work (if I block your SSH access to a server it should not only block new sessions but also terminate all running sessions).

[RafaelGSS]

+1 - I can work on it if you don't need to rush on it.

[mcollina]

+1 - I can work on it if you don't need to rush on it.

Go ahead! Not needed immediately but something that would be good to have.
(I would have thrown this at the clanker)

[mcollina]

@ChALkeR description updated

[absidue]

Just to be clear I am +1 on this too.