FAQ
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

--
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 nodejs@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.

Search Discussions

  • Matt at Nov 3, 2014 at 4:22 am
    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.
    On Sat, Nov 1, 2014 at 2:06 PM, Tim Kuijsten 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
    [2] 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
    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 nodejs@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.
    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAPJ5V2ZkAe1Fp2kXi%2BBs3vRZo85HxsSY7rk%2BOupG4x-bJuXk3g%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tim Kuijsten at Nov 3, 2014 at 4:02 pm

    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 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
    To post to this group, send email to nodejs@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+unsubscribe@googlegroups.com
    To post to this group, send email to nodejs@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>.
    For more options, visit 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+unsubscribe@googlegroups.com.
    To post to this group, send email to nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/54579813.10004%40netsend.nl.
    For more options, visit https://groups.google.com/d/optout.
  • Sam Roberts at Nov 3, 2014 at 5:07 pm

    On Mon, Nov 3, 2014 at 6:58 AM, Tim Kuijsten 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?

    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CACmrRmTvC-n76ZoR9M%2B9mc8btgd_ejqjBTMEAXYWAAELv0Ad%2BQ%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Tim Kuijsten at Nov 3, 2014 at 7:06 pm

    Sam Roberts schreef op 03-11-14 om 17:55:
    On Mon, Nov 3, 2014 at 6:58 AM, Tim Kuijsten 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

    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/5457D0B5.8030903%40netsend.nl.
    For more options, visit https://groups.google.com/d/optout.
  • Sam Roberts at Nov 3, 2014 at 8:59 pm

    On Mon, Nov 3, 2014 at 11:00 AM, Tim Kuijsten 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

    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CACmrRmQNVD8FZZ2PW0PXjcCNFLsdU7eOpZMS0RDCpj9MUr49Fg%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Alex Kocharin at Nov 3, 2014 at 9:40 pm

    03.11.2014, 23:59, "Sam Roberts" <sam@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?

    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/2291831415050488%40web15h.yandex.ru.
    For more options, visit https://groups.google.com/d/optout.
  • Aria Stewart at Nov 3, 2014 at 9:49 pm
    I'm curious about browserid though. Is it already used somewhere in the wild?
    https://login.persona.org


    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/E4D3E0B6-E13A-4A92-BF25-0789016A06C1%40nbtsc.org.
    For more options, visit https://groups.google.com/d/optout.
  • Tim Kuijsten at Nov 3, 2014 at 9:50 pm
    Alex Kocharin schreef op 03-11-14 om 22:34:
    03.11.2014, 23:59, "Sam Roberts" <sam@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?
    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

    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/5457F860.10207%40netsend.nl.
    For more options, visit https://groups.google.com/d/optout.
  • Tim Kuijsten at Nov 7, 2014 at 7:29 pm

    Sam Roberts schreef op 03-11-14 om 21:50:
    On Mon, Nov 3, 2014 at 11:00 AM, Tim Kuijsten 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
    --
    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 nodejs@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/545A8BCC.9080203%40netsend.nl.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupnodejs @
categoriesnodejs
postedNov 1, '14 at 9:54p
activeNov 7, '14 at 7:29p
posts10
users5
websitenodejs.org
irc#node.js

People

Translate

site design / logo © 2022 Grokbase