On Thu, Jan 31, 2013 at 5:59 PM, Jan Lehnardt <[email protected]> wrote:
> > On Jan 31, 2013, at 17:54 , Jason Smith <[email protected]> wrote: > > > On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau <[email protected] > >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 > -- what do you mean by short-lived? The call vm.runInNewContext(safe_context) launch a new child then kill it ? - benoît
