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.).
