[sramam]

Permissions are a whitelist.

While the grant is a blanket grant to a program and all dependencies, typically, a well behaved program will seek a limited scope of permissions. Like "https://my-program.com", "https://preferred-analytics.com" etc.

This prevents dependencies from using call back locations that are outside the permitted list, preventing much of the nefarious activity they can dream up.

If a dependency needs access to specific resources, it can advertise this fact and the parent module can in turn request this from the user.

Importantly, the user is explicitly aware of these & controls it in an absolute sense, at run time.

[ljackman]

The whitelisting looks great. Even with the remaining concerns I raised in the other comment, the ability to whitelist only allowed domains for network connections is a massive step up security-wise, even if they are allowed for the entire program (until revoked globally).

[hn_throwaway_99]

I'm not an expert on this in any sense, but would it be possible to add this into Node at the OS level, e.g. make use of network namespaces to restrict outbound network access?

[thegagne]

Yeah, the OS or network firewall can do this, but security happens in layers, and to me it makes sense that an app config is the place to put a whitelist for the apps network needs.

If I was just spitballing an ideal scenario, I’d suggest that each module would define what it needs, and then some sort of central file would be built to hold the aggregate of them (urls / modules), for easy scanning.

The reason I’d rather have it in the app is if you are switching platforms, you don’t need to worry about firewall configs being exactly the same, or being fine grained. Also you might be whitelisting up ranges on the network level, then locking it down further on the app level.

[hn_throwaway_99]

> Importantly, the user is explicitly aware of these & controls it in an absolute sense, at run time.

I mean, I guess I see value there for the use case of "I want to download a script to run locally on my machine" type of thing, but for the most common use of Node, i.e. I'm running a server process, does this really even matter?

[zamadatix]

I think the most common use of Node might actually be Electron if you go by number of users.

[sramam]

For most networked applications, there are two classes of permissions control - inbound and outbound.

The inbound is a run-time decision and dynamic at that - Firewalls, WAFs etc. are used for control. These are not (and probably should not) be set by the application author, but by the application operator.

The outbound however, is typically something that is designed into the application - it should be specified by the author, be available for auditing - both on first install and all subsequent changes. IMHO, this is where these whitelists shine.

For the server example you mention, whitelists don't prevent a malicious dependency from using your CPU for mining. With deno, by default, there is no way to dial-home the proof-of-work and collect the reward. Eventually, as the operator of the service, you'll notice a performance/cost problem and detect the malicious activity.

[LunaSea]

The file system module's permissions are however still vulnerable to symlinks for example:

https://github.com/denoland/deno/issues/2318