privilege separation

[Tim Kuijsten]

Can anyone confirm my assumption that splitting my node server process
into an unprivileged child that handles incoming network connections and
a privileged parent that has access to a password database prevents
attacks on the V8 network layer where an attacker would otherwise be
able to get privileged access.

The only communication between the parent and the child occurs over an
IPC channel where the parent only accepts simple and strictly typed JSON
messages.

I'm trying to build a server and apply some privilege separation
techniques [1] comparable to how OpenSSH is doing this [2]. But I'm a
bit insecure if these techniques really make sense in a garbage
collected and interpreted language like JavaScript. I can imagine it
only mitigates against flaws in V8, OpenSSL, libuv and any other bundled
C code, but not so much against flaws in the JS I write myself.

-Tim

[1]
https://github.com/Netsend/mastersync/wiki/Mastersync-privilege-separation
[2] http://www.citi.umich.edu/u/provos/papers/privsep.pdf

[Matt]

You're basically correct in that it really protects against segmentation faults (and other things like that) allowing access to memory regions that the code shouldn't access, and as such in theory V8 shouldn't be vulnerable to such things.

Having said that, it's not a terrible idea to implement this kind of thing, it just seems like you may be over-thinking it. It's far more important to get the basics of security right in your application, and most people don't spend nearly enough time on that.

Matt.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
--- You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscribe@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/54552135.4010602%40netsend.nl.
For more options, visit https://groups.google.com/d/optout.

[Tim Kuijsten]

Matt schreef op 02-11-14 om 22:01:

> You're basically correct in that it really protects against segmentation
> faults (and other things like that) allowing access to memory regions
> that the code shouldn't access, and as such in theory V8 shouldn't be
> vulnerable to such things.

On second thought, since V8 and thus the JavaScript code is part of
these memory regions, anything including the JS might be compromised by
a vulnerability in any of the C code.

>
> Having said that, it's not a terrible idea to implement this kind of
> thing, it just seems like you may be over-thinking it. It's far more
> important to get the basics of security right in your application, and
> most people don't spend nearly enough time on that.

Agree, it's just an extra mitigation to make my server more secure in
the hope that it gets widely deployed. And it's not that hard to
separate privileges if you're still in the developing phase. It will be
painful to retrofit it in existing monolithic servers, so I hope this
design pattern will be used more when building new (nodejs) servers.

-Tim

>
> Matt.
>
> On Sat, Nov 1, 2014 at 2:06 PM, Tim Kuijsten <in...@netsend.nl
> <mailto:in...@netsend.nl>> wrote:
>
> Can anyone confirm my assumption that splitting my node server
> process into an unprivileged child that handles incoming network
> connections and a privileged parent that has access to a password
> database prevents attacks on the V8 network layer where an attacker
> would otherwise be able to get privileged access.
>
> The only communication between the parent and the child occurs over
> an IPC channel where the parent only accepts simple and strictly
> typed JSON messages.
>
> I'm trying to build a server and apply some privilege separation
> techniques [1] comparable to how OpenSSH is doing this [2]. But I'm
> a bit insecure if these techniques really make sense in a garbage
> collected and interpreted language like JavaScript. I can imagine it
> only mitigates against flaws in V8, OpenSSL, libuv and any other
> bundled C code, but not so much against flaws in the JS I write myself.
>
> -Tim
>
> [1]

> https://github.com/Netsend/__mastersync/wiki/Mastersync-__privilege-separation
> <https://github.com/Netsend/mastersync/wiki/Mastersync-privilege-separation>
> [2] http://www.citi.umich.edu/u/__provos/papers/privsep.pdf

> <http://www.citi.umich.edu/u/provos/papers/privsep.pdf>
>
> --
> Job board: http://jobs.nodejs.org/
> New group rules:

> https://gist.github.com/__othiym23/9886289#file-__moderation-policy-md

> <https://gist.github.com/othiym23/9886289#file-moderation-policy-md>
> Old group rules:

> https://github.com/joyent/__node/wiki/Mailing-List-__Posting-Guidelines

> <https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
> --- You received this message because you are subscribed to the
> Google Groups "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to nodejs+unsubscribe@__googlegroups.com
> <mailto:nodejs%2Bunsu...@googlegroups.com>.

> To post to this group, send email to nod...@googlegroups.com

> <mailto:nod...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/__msgid/nodejs/54552135.4010602%__40netsend.nl
> <https://groups.google.com/d/msgid/nodejs/54552135.4010602%40netsend.nl>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> Job board: http://jobs.nodejs.org/
> New group rules:
> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
> Old group rules:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> ---
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to nodejs+un...@googlegroups.com
> <mailto:nodejs+un...@googlegroups.com>.

> To post to this group, send email to nod...@googlegroups.com

> <mailto:nod...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/nodejs/CAPJ5V2ZkAe1Fp2kXi%2BBs3vRZo85HxsSY7rk%2BOupG4x-bJuXk3g%40mail.gmail.com
> <https://groups.google.com/d/msgid/nodejs/CAPJ5V2ZkAe1Fp2kXi%2BBs3vRZo85HxsSY7rk%2BOupG4x-bJuXk3g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Sam Roberts]

On Mon, Nov 3, 2014 at 6:58 AM, Tim Kuijsten <in...@netsend.nl> wrote:
> Matt schreef op 02-11-14 om 22:01:

>> Having said that, it's not a terrible idea to implement this kind of
>> thing, it just seems like you may be over-thinking it. It's far more
>> important to get the basics of security right in your application, and
>> most people don't spend nearly enough time on that.

Tim, is your server storing passwords in plain text? If so, that's
probably your biggest security problem.

And how are you dropping privileges in your child? If the child can
get the privileges back, you have separation of responsibility, but
not separation of privileges.

And in terms of future-proofing your architecture, you might consider
implementing user-authentication as
an arbitrary separate process, not the parent, to give you the ability
to use different authentication schemes.

Have you considered OAUTH, so that passwords don't flow through your
server at all?

[Tim Kuijsten]

Sam Roberts schreef op 03-11-14 om 17:55:

> On Mon, Nov 3, 2014 at 6:58 AM, Tim Kuijsten <in...@netsend.nl> wrote:
>> Matt schreef op 02-11-14 om 22:01:
>>> Having said that, it's not a terrible idea to implement this kind of
>>> thing, it just seems like you may be over-thinking it. It's far more
>>> important to get the basics of security right in your application, and
>>> most people don't spend nearly enough time on that.
>
> Tim, is your server storing passwords in plain text? If so, that's
> probably your biggest security problem.

Hi Sam, yes, but I'll use a file that only the superuser can read. The
privileged process reads this file before it chroots and drops
privileges itself. It's completely apart from the unprivileged child.
Ofcours the unprivileged child starts as a superuser as well, but drops
privileges before it starts listening to the network [1].

>
> And how are you dropping privileges in your child? If the child can
> get the privileges back, you have separation of responsibility, but
> not separation of privileges.

I've written a little chroot helper to do this securely, though I would
appreciate some peer review [2].

>
> And in terms of future-proofing your architecture, you might consider
> implementing user-authentication as
> an arbitrary separate process, not the parent, to give you the ability
> to use different authentication schemes.

This is a good one, ideally I switch to public key auth. I tried to
built my own with the node tls lib but I'm not confident enough this
would be secure. If gryphon [3] wasn't built on http this would have
been a good contender, for now I stick with shared secrets (bcrypt).

>
> Have you considered OAUTH, so that passwords don't flow through your
> server at all?

Given the controversy around oauth2 [4] I haven't looked deep into it.
From a distance it looked a bit complex. I really liked the BrowserID
proposal [5], although this one is centered around the browser. Maybe
plain x509 certs will do. As you can see I still haven't made up my
mind. Maybe I have to give the tls lib another try someday (maybe if
LibreSSL's libtls, formerly known as ressl [6], makes it into nodejs?).

-Tim

[1]
https://github.com/Netsend/mastersync/blob/privsep/lib/preauth_exec.js#L126-L138
[2] https://www.npmjs.org/package/chroot
[3] https://github.com/seanmonstar/gryphon
[4] https://en.wikipedia.org/wiki/OAuth#Controversy
[5] https://github.com/mozilla/id-specs/blob/prod/browserid/index.md
[6] http://www.tedunangst.com/flak/post/goreSSL

[Sam Roberts]

On Mon, Nov 3, 2014 at 11:00 AM, Tim Kuijsten <in...@netsend.nl> wrote:

>> Tim, is your server storing passwords in plain text? If so, that's
>> probably your biggest security problem.
>
> Hi Sam, yes, but I'll use a file that only the superuser can read.

That's what i meant, anyone who roots your server owns your passwords.
Check out SRP, or more modern equivalents:
http://en.wikipedia.org/wiki/Password-authenticated_key_agreement

chrooting and dropping is a good thing, but its not like no attacker
has ever gotten out of a chroot jail, or just decided the http server
wasn't the weakest link, and got in some other way. If you are going
through this trouble, you may want more depth to your defence.

>> Have you considered OAUTH, so that passwords don't flow through your
>> server at all?
>
> Given the controversy around oauth2 [4]

One loud critic doesn't equate to a controversy. And there is both
OAUTH and OAUTH2. They only work for web-clients, of course, so may
not be appropriate for your use. No keying material on your server has
some nice security properties.

Cheers,
Sam

[Alex Kocharin]

03.11.2014, 23:59, "Sam Roberts" <s...@strongloop.com>:

>>>  Have you considered OAUTH, so that passwords don't flow through your
>>>  server at all?
>>  Given the controversy around oauth2 [4]
>
> One loud critic doesn't equate to a controversy.

Yes, it does if arguments he makes are valid.

oauth and oauth2 are completely different things though. First one is a good thing that worth looking into, although signature is a bit too complex. Second one isn't even a proper standard, because there is no interoperability.

I'm curious about browserid though. Is it already used somewhere in the wild?

[Aria Stewart]

> I'm curious about browserid though. Is it already used somewhere in the wild?

https://login.persona.org

[Tim Kuijsten]

Alex Kocharin schreef op 03-11-14 om 22:34:

Well by Persona, which is a project originally started by Mozilla.
Unfortunately they dropped it earlier this year though it seems like the
community took over [1][2]. You can still login using Persona on
different Mozilla websites, not sure about it's adoption outside of Mozilla.

Personally I'm not interested in protocols based on HTTP [3]. And the
server I'm currently building uses a very simple JSON (for initial auth)
+ BSON (for data) wire protocol over TCP.

[1] https://github.com/mozilla/persona
[2]
http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership
[3]
https://groups.google.com/forum/?fromgroups=&hl=nl#!searchin/mozilla.dev.identity/timkuijsten/mozilla.dev.identity/L2ETKkdMv8g/q3ffwFaJgl0J

[Tim Kuijsten]

Sam Roberts schreef op 03-11-14 om 21:50:

> On Mon, Nov 3, 2014 at 11:00 AM, Tim Kuijsten <in...@netsend.nl> wrote:
>
>>> Tim, is your server storing passwords in plain text? If so, that's
>>> probably your biggest security problem.
>>
>> Hi Sam, yes, but I'll use a file that only the superuser can read.
>
> That's what i meant, anyone who roots your server owns your passwords.
> Check out SRP, or more modern equivalents:
> http://en.wikipedia.org/wiki/Password-authenticated_key_agreement

This PAKE looks interesting, though I'll save it for another day.

It's perfectly fine to run the server I'm currently building without
listening on a public interface at all. Furthermore it has both a client
and a server in it and for a lot of users it will be sufficient to run a
server only or a client only (I guess a peer would be a better name).
The plain text passwords are only needed in the client part, since the
server currently hashes them using bcrypt. This makes it impossible to
grab all passwords at once from a "server-only" installation.

For those users that do choose to run a publicly accessible server I'm
taking extra measures to mitigate the general risks that come with
running a public server (since making V8, libuv etc. reachable over the
internet will extend the attack surface significantly).

>
> chrooting and dropping is a good thing, but its not like no attacker
> has ever gotten out of a chroot jail, or just decided the http server
> wasn't the weakest link, and got in some other way. If you are going
> through this trouble, you may want more depth to your defence.

You're right that escaping a chroot is often not impossible. The nice
thing about a chroot though is that it's pretty universal (well, at
least on POSIX systems) and not a Linux or other OS specific thing. And
I'm told that when it's done right, it's extremely hard or even close to
impossible to escape (it's heavily used on OpenBSD for example, a system
I trust). Ofcours, the chroot npm needs more refinement before I'm
confident it can give such guarantees.

The privilege separation is mainly to mitigate the risks that the server
I'm building is adding to you're infrastructure, not about mitigating
any other risks a certain server might already have that is unrelated to
running my software.

>
>>> Have you considered OAUTH, so that passwords don't flow through your
>>> server at all?
>>
>> Given the controversy around oauth2 [4]
>
> One loud critic doesn't equate to a controversy. And there is both
> OAUTH and OAUTH2. They only work for web-clients, of course, so may
> not be appropriate for your use. No keying material on your server has
> some nice security properties.

I agree on the "No keying material on your server has some nice security
properties" proposition.

Although unrelated, this reminds me of some interesting things that are
done at Twitter when utilizing forward secrecy on multiple front-end
servers "You need to generate session ticket keys randomly, distribute
them to the servers without ever touching persistent storage and rotate
them frequently." https://blog.twitter.com/2013/forward-secrecy-at-twitter

Thanks,

Tim

>
> Cheers,
> Sam
>