On Jan 31, 2013, at 17:54 , Jason Smith <j...@iriscouch.com> wrote: > On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau <bchesn...@gmail.com>wrote: > >> >> A javascript engine doesn't expose any IO par default. The **framework** >> nodejs is, this is all the point. I'm quite interested by the existing >> solutions to sandbox nodejs, do you know some projects that does it? >> > > Correct. I am attempting to build something which satisfies your > description: no i/o; i/o is not even possible. > > *How* is it implemented? Well, it doesn't matter whether we use Node.js or > couchjs/SM or couchjs/v8. What matters is we feel confident about security. > And of course, I agree, if we cannot achieve good security, then that is a > show stopper. > > Here is my current plan for sandboxing CouchJS. (Thanks to Isaac for his > tips.) > > When it is time to evaluate some code: > > 1. Set up an object with safe variable bindings: safe_context > 2. fork() > 3. Child process runs vm.runInNewContext(safe_context) > 4. Child process communicates to the parent over stdio, through the > approved safe_context functions > > The subprocess can also give extra sandboxing, such as chroot() if > available. > > Yes, this causes two processes per instantiation; however I think the > parent might only be short-lived, setting up the security, then exiting. > The grandchild can talk to Erlang over stdio. > > That is my plan. No idea how well it will work.
This would of course fork 2 node processes per view server launch. I think this isn’t too bad, especially when the one is short lived, but it’d be nice if we can avoid that. Luckily, we can then easily experiment with the query server protocol and make this all a non-issue. Woot! Jan --
