You're basically correct in that it really protects against segmentationOn 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.
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.
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.
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.
>> 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?
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].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.
I've written a little chroot helper to do this securely, though I would appreciate some peer review [2].
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.
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).
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.
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?).
Have you considered OAUTH, so that passwords don't flow through your
server at all?
>> 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/
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.
>>> 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?
> I'm curious about browserid though. Is it already used somewhere in the wild?
https://login.persona.org
Have you considered OAUTH, so that passwords don't flow through yourGiven the controversy around oauth2 [4]
server at all?
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/per
[2] http://identity.mozilla.com/po
[3] https://groups.google.com/foru
This PAKE looks interesting, though I'll save it for another day.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_agre ement
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/
댓글 없음:
댓글 쓰기