On 12/17/2013 01:24 PM, Alex Kocharin wrote: > 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? Much of what has been suggested above makes sense to me. yes! I think it would align with the http://en.wikipedia.org/wiki/Principle_of_least_privilege to do as suggested and limit a module to some capabilities it actually needs (for its supposed task). This way it would stand out and be more apparent. If for instance a sorting allgorithm needs fs. writing priviledges this would seem odd, right?
> Or javascript is just too dynamic for any of this to work, and it's a > performance nightmare to freeze everything? There might be costs involved. a) those cost to defined which stuff a module needs (so that it can be granted those things, without much effort. ) b) also some very little overhead cost of the to restrict the priviledes before before consuming the module. Via closure it should be possible to keep stuff separated.. (sadly it might also provoke the opposite). I am optimistic it would not generate a perfomance nightmare necessarily. Since for instance functions in JS are already unaware of much stuff there seems to be a chance to clear capablities from global access and have it only handed to those module/code parts which require it and hence have them inside their closure scope. Actually I think its because Javascript is so dynamic, that I am optimistic that some priviledge dropping mechanism can be engineered -- -- 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.
