Exploring security policies in Node core

[drifkin]

In the the security-wg Slack, we've been discussing what policies in Node core might look like: https://nodejs-security-wg.slack.com/archives/C9KTR110F/p1529928028000444

This discussion largely started due to Ryan Dahl's talk at JSConf EU 2018, where he gives an example that "your linter shouldn't get complete access to your computer and network".

In the Slack discussion, we talked about different kinds of policies, and different attacker models. @brycebaril from NodeSource talked about some of the policies they offer, and mentioned that he'd be interested in these coarse-grained policies being implemented in core.

I also chimed in with some thoughts about policies and attacker models, since this is mostly what we do at Intrinsic.

This is all very speculative, but moving forward, there's been interest from other members of the group in further exploring this concept.

I think it's reasonable to start the discussion with very coarse-grained policies (e.g., does this Node process get to use the network or not?). We'll need to decide the list of policies we'd like to support. We'll need to decide if we're defending against well-meaning, yet buggy code, or actively malicious code. And depending on that answer, we'll have lots of details to work through (e.g., if you turn off networking, are you still allowed to spawn child processes that might use the network?). And finally, once we know what we'd like to build, we can figure out if it's feasible.

[mhdawson]

This sounds like a great idea to me, and good to get the discussion into an issue were everybody can contribute.

[vdeturckheim]

We might want to involve folks from the Module Team here.
I think having process-level policies is the best first step to iterate from.

I have to check if I can free some time to spend on this issue. But that's super exciting.

[bmeck]

I also chimed in with concerns about exceptions to policies and resource integrity checks. In particular I want to evaluate the granularity of permissions and sharing. Node's core is not incredibly robust and can easily be mutated in ways to make it less robust; leaking permissions seems realistic so I think these measures are more suited for accidental usage and real security is going to keep relying on ensuring auditing of code which we also cannot currently enforce on code being evaluated within Node.

[mikesamuel]

What do I need to do to get into this conversation?

I've been working on how to reserve privileges to some modules but not others.

That seems to require some notion of module identity.
module-keys provides a notion of module identity that resists impersonation.

Being able to open a sink like eval to some modules but not others could benefit from letting some module's mint inputs that would be trusted by eval and node-sec-patterns builds on module-keys to provide configurable white-lists of modules allowed to create values of a particular contract type.

Finally, gating access to commonly misused sources of authority like child_process requires module loader hooks. I have a runtime patch that redoes @bmeck's module resolver hooks for require and am working on babel plugin that does the same for an unpatched runtime.

[drifkin]

@mikesamuel: I'm trying to get the conversation to be in the issue tracker as much as possible so that it's accessible and easy to look at the history as we move forward exploring these topics. So consider yourself part of the conversation!

On Slack, we've started to talk about maybe meeting up at Node Summit. Will you be around by any chance? (by the way, to join our Slack, go to https://nodejs-security-wg.herokuapp.com/, but I'd prefer to move as much of the conversation to this issue tracker as possible).

Thanks for linking to module-keys! I looked at it really briefly, but from the README, it looks like you're leaning towards protecting well-meaning code, rather than malicious code:

Module keys allow code written in good faith to cooperate while avoiding lowest-common-denominator security problems. It does not allow safely running malicious code within the same process. Potentially malicious code should be sandboxed if it needs to run at all.

Do you think that's a good model to aim for for initial policies in core (I think this is one of the first things we need to decide)? I'll take a closer look at your module in the coming days.

[vdeturckheim]

Worst thing we could do would be to ship a mechanism that would give a false sense of security to the users.
In a first time, preventing a whole node process from loading a set of modules altogether (like net, http(s|2), dns and udp) or preventing the process from writing any file but still allowing to read some, would be a great PoC IMHO

I believe having a fine per module permission system, would require at least long stacktraces everywhere which, even with Async Hooks is not granted.

I'll be staying in SF a few days after Node.js Summit and would be available for a physical + hangout work session on that topic.

[drifkin]

@vdeturckheim: if I'm understanding you correctly, you're saying that we should only consider policies resilient against malicious attackers?

I think that's worth exploring (and in fact is what we do at Intrinsic, though the other details are quite different: we have very fine-grained policies and many isolation contexts), but that implies a lot of other complications. For example, for the PoC you described, would you disallow all native modules and child processes (otherwise a malicious attacker can just reimplement that functionality themselves)? We'd also need to make changes to Buffer: consider that you can turn off bounds checking in many operations and also allocate memory without zero-filling). A malicious attacker model would also mean that we'd probably need to fix all of the binding issues that so far have been out of scope (discussed a bit in #18, and some more background in issues like nodejs/node#9821).

In my opinion, I think per-module policies don't make sense combined with a malicious attacker model (without massive semantic changes): modules need to interact too much with each other and it will be very difficult for users to think about the effect of the policies.

(btw, I'm out of town starting July 27, and unavailable on the 25th, so I'd prefer to meet on the 24th or 26th if possible)

[deian]

An in person meeting would be very useful. I'll also be speaking about binding bugs at Node Summit FWIW.

My 2c on the above discussion(s): I think scoping the attacker model and kinds of policies (at a high level) we want is the most important thing to try to tackle first. I'm worried about introducing mechanisms before we figure these things out.

[mikesamuel]

@drifkin said

On Slack, we've started to talk about maybe meeting up at Node Summit. Will you be around by any chance?

Yep. I'm talking at 11:35 on day 1 about "Improving Security by Improving the Framework." </plug shameless>

Thanks for linking to module-keys! I looked at it really briefly, but from the README, it looks like you're leaning towards protecting well-meaning code, rather than malicious code:

Yes. I think that running user code in the same realm as process.binding (absent Intrinsic's membrane) is a non-starter which means that nothing short of frozen realms will allow true mutual suspicion. I also think true mutual suspicion is not the right model for mitigating damage due to bugs in code produced by trusted developers or third-party modules chosen by them.

Do you think that's a good model to aim for for initial policies in core (I think this is one of the first things we need to decide)? I'll take a closer look at your module in the coming days.

Without access to the prior discussion I'm not sure I can answer that question.

In my experience, in-realm language based enforcement mechanisms and boundary mechanisms like Intrinsic's filtering membranes or syscall filters are often complementary.

+1 to what @deian said. Expanding on the different models and exploring how they fit together would be a good use of time at the summit.

@vdeturckheim

Worst thing we could do would be to ship a mechanism that would give a false sense of security to the users.

This is a good point. I think we need to clearly communicate what we provide w.r.t. confidentiality.
Someone wrote a fictional account of an NPM module that exfiltrated secrets which I'm having trouble finding a link for. Solving this requires solving side channels and spectre also means that even if we can limit the side effects that injected code can cause, we can't solve exfiltration. So unless we provide a way to move secrets out of process, we can provide few hard confidentiality guarantees.

I think we can provide plenty of integrity improvements though.

In a first time, preventing a whole node process from loading a set of modules altogether (like net, http(s|2), dns and udp) or preventing the process from writing any file but still allowing to read some, would be a great PoC IMHO

I presented a demo of some of this in my recent jsconf.eu talk.
Using a combination of module resolver hooks and contract types, I dynamically enforce several properties:

• XSS: That an http response body is the concatenation of strings from whitelisted source modules.
• Shell Injection: That a shell command comes from a whitelisted source known to properly escape, sh-template-tag.
• Attacker controlled string reaches require: That only files recognized as production sources load in production and have recognized hashes.

https://github.com/mikesamuel/jsconf-eu-2018
I'm happy to recap if we meet up at the Node summit.

[vdeturckheim]

<side_node>@mikesamuel I think we have to grab a drink at Node Summit to discuss your last presentation and compare how Sqreen works with that.</side_node>

I will be in SF from Sunday July 22nd to Saturday July 28 (mid day) and I am mostly needed at the conference on day 2.

• What day would work best for everyone to meet (keeping in mind that we might have a few people through Hangout (@bmeck)) ?
  • What about Monday in the afternoon?
• If we meet outside of conference time, do we have a place to meet? (Sqreen's office in SF are still too small for us to be able to host this)
  • cc @brycebaril maybe?
• If we meet during the conference, should I ask the organizer if we can have a room?

[mikesamuel]

@vdeturckheim
Sounds lovely.
I tend to sit in a corner with a laptop mumbling to myself for several hours before I present so anything but morning of day 1 works for me.

[mhdawson]

I'm around on the 26th. I'm pretty busy the three days of the conference.

[mhdawson]

My first 2 cents is that we should include thinking about what "hooks" in node core would allow additional controls to be added as opposed to everything being part of core itself (in keeping with the small core philosophy). Might not be possible due to overhead but worth including as part of the discussion/thinking.

[vdeturckheim]

@mhdawson definitely. I don't want us to end up with a domain-like feature with impacts everywhere in the codebase. However that might be an optimistic wish.

[drifkin]

From this thread, it sounds like the 26th (the day after Node Summit) would work the best to meet up to discuss policies.

/cc @mhdawson @mikesamuel @vdeturckheim

Who else is interested? We'd be happy to host at the Intrinsic offices (we're in the financial district in SF).

@bmeck are you still interested in joining remotely?