Isaac, I am particularly interested in multi-tenancy, could list a few of the technologies that you mention in your last reply?
Thanks, Gustavo On Fri, Aug 3, 2012 at 2:51 PM, Isaac Schlueter <[email protected]> wrote: > 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 <[email protected]> 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.).
