On Thu, Jan 31, 2013 at 5:54 PM, 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. > > -- > Iris Couch
Too much kool-aid imo :) This is not that it can't work. But are you seriously considering to have a main couchjs process maintaining the STDIO channel and spawn a new OS Process for a view (which what does `vm.runInNewContext`)? The memory and latency cost can became very important, and i don't count the chrooting cost especially if run this context on each indexation batch or shows, lists and views requests. + the extra fds created by each child contexts. Anyway, I looked over the week-end and didn't find so may other solutions when it's about nodejs. I read that and maybe ` vm.runInContext` [1] with `vm.CreateContext` could work or like Klaus says maybe `vm.CreateScript` though the doc[1] don't say if it s in the same process or not [2]. I guess it is. I'm interested by the solution of providing a secure "require" like suggest Klaus. How would it work? I intend to write a straight-forward port of couchjs to use v8 to see how much things it gave us, but it will be just a temporary hac, just good for 1.4 imo. I also would like to find a solution for the mobile worl and i'm not sure v8 is OK for that yet. Just some thoughts, it's cool to see such activity on this topic :) - benoît [1] http://nodejs.org/api/vm.html#vm_vm_createcontext_initsandbox [2] http://nodejs.org/api/vm.html#vm_vm_createscript_code_filename [3] http://nodejs.org/api/vm.html#vm_sandboxes
