I've used both Solaris Zones and Linux Containers. They work well and cover most of these problems at the OS level. Also depending on how much sandbox you need, just using a child-process optionally in a chroot may be enough. But child-process + chroot is NOT a complete solution and evil users can cause trouble from within those.
On Fri, Aug 3, 2012 at 1:04 PM, Gustavo Machado <[email protected]> wrote: > 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.).
