Adding filesystem and http(s) security

[intervalia]

What is the problem this feature will solve?

I keep thinking that Node needs to add some level of security for both the filesystem and http(s) communications and probably other things too. I know that DENO makes great claims on security, though I admit not reading about HOW they do it.

This is just an idea to get people thinking and, hopefully, get something built into Node.

This would prevent rogue packages from doing things they are not allowed to do.

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

I would love to see node, by default, not allow any filesystem reads or writes and not allow any http(s) communications. This could be an option with a command line flag, but I would love to see it standard.

Then the developers would provide a "rights" file. This file would allow the developer to include read and write access folders in the file system as well as valid URLs that can be accessed. Again this model could extend to other things that could be abused.

The file could be a simple JSON file that provides the list of whitelisted folders and urls for this application. Something like this:

{
  "folders": {
    "./storage": "rw",
    "./options": "r",
    "./dowloads": "w"
  },
  "domains": {
    "www.something.com": "r",
    "www.myapisite.com": "rw"
  }
}

This is just an example to get people thinking.

You could also open things up 100% by doing something like this:

{
  "folders": {
    "/**": "rw"
  },
  "domains": {
    "*": "rw"
  }
}

I would love to see Node.js become more secure and this could be a great step to seeing that future.

What alternatives have you considered?

I don't know of any way to make the filesystem and http(s) secure in node. It allows access to anything the OS allows access to.

[benjamingr]

@intervalia is there any reason you don't use the existing tools (like containers) to do this?

The problem with this sort of limiting (there is some through policies but that hasn't seen widespread adoption yet) is that it's very easy to get a false sense of security whereas tools like container technologies provide real and pen-tested isolation through OS level APIs.

[jasnell]

This is definitely a non-trival issue. See here for a discussion of some of the complexities involved: https://www.nearform.com/blog/adding-a-permission-system-to-node-js/

A key part of the complexity here is that Node.js internals use exactly the same code paths as user code for things like network and file system access. Locking them down for one but not the other is difficult and requires a very large overall change. Also, we have to consider native code layers (native addons, child processes, etc), user interactivity factors (e.g. when and how to ask for permissions, etc), and how to to model the permission space.

As @benjamingr points out, for many environments, wrapping in a sandboxed container is much easier overall. Obviously, however, that only helps in certain environments. Running Node.js on a Windows desktop, for instance, the sandbox configuration of a docker container isn't going to help you much.

I'd love to see us make progress here but it is absolutely going to be non-trivial at best to implement. Happy to help tho.

[intervalia]

Containers still do not prevent rogue repos from doing things they should not be allowed to do.

If I can lock out my filesystem, or, at least, the config file, and then prevent the application from hitting ANY url not in my whitelist then I can prevent a rogue repo from sending tracking info to some other site.

We have had several situations where rogue repos have done some very harmful things and I am proposing a basic filter mechanism at a very low level to prevent that harm in the future.

Yea, I figured it would be hard, but I believe it is still needed. Some companies I have worked for are starting to ban the use of Node because it is wide open. I do think the work would be worth it since everyone would gain a real level of security.

To resolve the internal system problems you could have an auto-inclusion of the entire node-modules folder with read rights.

Again, I am not claiming to have thought this through 100%, but I wanted to get others thinking about it and, I hope, lead to several discussions of how to make it work as simply as possible.

[Trott]

Prior discussions:

• Secure Node security-wg#457
• [WIP] src,lib: policy permissions  #33504
• Suggestion: add standard methods to limit APIs dependencies can use package-maintenance#92

[mscdex]

Some companies I have worked for are starting to ban the use of Node because it is wide open.

Banning the use of node for that reason is quite silly. Node is no different than most other server-side languages in that regard. Ultimately you should be using operating system-level protections instead of relying on high-level restrictions (not only the availability of such restrictions but that they are reliable/bug-free).

[benjamingr]

@intervalia

Containers still do not prevent rogue repos from doing things they should not be allowed to do.

Can you elaborate on this? Intuitively they literally do - containers limit the network, cpu and file system of what code that runs inside them can do with granular and battle tested permissions. You can limit container networking in a much more granular than a "by url" basis (disable networking, route network through any proxy or firewall etc).

I would much rather see a "run Node.js inside docker with better dx when developing locally" tool that automatically wires things and sets up the inspector for debugging than a home-baked solution that would likely not work against a determined attacker because the limiting is applicative anyway.

[intervalia]

While I agree that running in a container has its advantages, there are many people/projects that can't or wont.

Ryan Dahl felt that security in the node style environment was so important that he stopped working on Node and created Deno that has this level of security imbedded in it.

I really think adding some level of lockdown could be helpful for those of us that can't use Docker to prevent rogue repos from being able to do anything they want.

[benjamingr]

Ryan Dahl felt that security in the node style environment was so important that he stopped working on Node and created Deno that has this level of security imbedded in it.

Ryan hasn't been working on Node for many (6-7?) years before Deno and Deno's experimental security model hasn't convinced any security personnel I tried to pitch it to internally (at Microsoft) who all stated how easy it to make a single package requiring permissions (e.g. your logger needing http access and your cache requiring filesystem access) cause unrelated packages (e.g. a string formatter) to suddenly be able to read your ~/.ssh folder and send it to the attacker's backend.

I really think adding some level of lockdown could be helpful for those of us that can't use Docker to prevent rogue repos from being able to do anything they want.

What I'm reading is that Node should make it (much) easier to run and debug Node code inside containers (like Docker) when doing local development. It sounds like this would enable the use case here while allowing access to the huge container ecosystem which is both audited/pen-tested and is big and full of solutions to edge-casey problem. Would that help/work?

[intervalia]

I can tell this is getting nowhere. As I stated, there are those of that that can't or won't use container.
I still think this would be a great addition. You guys don't.

[benjamingr]

@intervalia just because I'm not convinced we should add filesystem and http security into core doesn't mean we can't talk about it, right?

Disagreements and (constructive) conflicts are fine (and good!) as long as we stay respectful/professional about it (so far the case I think?) - so I think it is very premature to call the discussion concluded.

Would it help if Node better integration that helps you seamlessly run node limited to a directory and with constrained http/cpu resources? Is the fact installing something (like docker) even if you are unaware of it when running node a show stopper?

[jasnell]

@intervalia ... Coming into this conversation with an attitude is not going to convince anyone. There are quite a few folks here that would like to see a reasonable permissions system put in place for Node.js but we are also realistic about what that means. To say that it is "non-trivial" is putting it mildly at best. Recognizing that a problem is difficult is not the same as not being interested in solving the problem.

Also, this is not Deno and decisions here are not motivated by comparison to whatever Deno is doing.

The most productive path forward is to start working towards concrete solutions on how we can make this happen in a way that addresses the many difficult technical issues involved. If you're willing and able to help have that conversation, then I think there's more we can discuss in this thread.

[Trott]

Closing in favor of nodejs/security-wg#791.