On Feb 5, 2013, at 08:26 , Benoit Chesneau <[email protected]> wrote:
> On Mon, Feb 4, 2013 at 6:58 PM, Jan Lehnardt <[email protected]> wrote: >> >> On Feb 4, 2013, at 18:47 , Benoit Chesneau <[email protected]> wrote: >> >>> On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt <[email protected]> wrote: >>>> >>>> On Feb 4, 2013, at 11:53 , Benoit Chesneau <[email protected]> wrote: >>>> >>>>> 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. >>>> >>>> Alternatively, if the above works and is necessary (modulo Klaus’s >>>> research), we live with the hit until we get to rewrite the view protocol >>>> at which point we can make it 1 Erlang process -> 1 node process for >>>> dispatching -> N Node processes for indexing. >>> >>> I don't think it is necessary at all to use so many *OS* process at >>> all for our purpose. And I am really worried by such solution.There is >>> a reason why people don't try to launch too much OS processes on the >>> system, There is a reason why we are using systems like Erlang. >>> >>> I guess runInContext would work, with a custom `require` function to >>> include modules (to specifically forbid IO) . According to the doc the >>> context doesn't share anything, which is what we want. Also if we are >>> going for node i would prefer to start with a straight forward >>> solution and not introduce any new behaviours. >> >> I suggested 1 extra node process in total, if at all, as an alternative, >> if the thing Klaus and you outline doesn’t work. >> > Why doesn't it work? I was speaking hypothetical. We’ll have to wait for the code & tests to see how it turns out. I am optimistic, I just wanted to leave open the possibility of us finding some blocker. Best Jan -- > > runInNewContext would imply to launch one new context / view if you > want to really run it sandboxed. > > "vm.runInNewContext compiles code, then runs it in sandbox and returns > the result.". > > I don't see any other way since you can't recycle a context in this > case. Having another I/O for this context wil be even uglier. In that > case you would have STDIO -> CHILD -> STDIO -> CHILD . Without > counting the memory usage it will add more latency than we have right > now. The more I think about that the more I'm reluctant to support > such solution. > > - benoît
