The problem with this kind of "hardened" approach is that Node has not been built with that in mind.
True security containment is not trivial. It's not a feature you add onto a platform later. It's something that you really have to bake into the architecture from the very start, and evaluate all your trade-offs in that light. And, if it's done halfway or badly, you end up with something that performs terribly and has lots of sticky bugs. Just look at the many trade-offs that have been made in the world of client-side JavaScript sandboxing, and the awful mess that is php safe mode. If you want containerization, I'd recommend using SmartOS and putting the contained programs in a zone. Trying to do this at the app level will always lead to headaches. Furthermore, doing multi-tenancy in this way is extremely dated, and unnecessary. There's better technology now. On Thu, Aug 2, 2012 at 4:52 PM, Bradley Meck <bradley.m...@gmail.com> wrote: > The problem with continually restricting things like child processes and > native addons, is that these are popular features, and you still face > problems like port/fd hijacking. Indeed removing child processes would help > as well as native addons, but this is a sieve. You expect the process to > protect you instead of the OS. fork() cluster etc. would have to be turned > off as well as running in a "nobody"-like user in order to help with file > system access combined with chroot, and the spawning process would have to > prevent file descriptor attacks. In order to prevent fd attacks and port > hijacking you would need your master process to give the actual fds to the > child after verifying them before opening them for the child in the first > place. After that, you would want to completely restrict the C++ level > access instead of Javascript as well, just to be safe that you did not miss > any dangling references (which you did at the node level, but ideally at > libsystem etc.). Other considerations are edge cases like INET_PORT_ANY. > > The list goes on an on and on for potential exploits and we may eventually > list most of them but it is improbable that we ever list all of them. I > compare this approach to opt-in security in Windows or using the VM module > to executed code, it is nice, but no guarantee. I recommend VM level > separation if you are serious about security combined with OS level > protection (file system attributes + RBAC etc.).
