On Sunday, 26 February 2012 07:52:53 UTC+1, deitch wrote: > > @Rob, > > Agreed, but capability sounds like something of a merger. In auth- > based, you separate authentication from authorization, and your > credentials only say who you are (authenticate), not what you can do > (authorization). Authorization is something that happens internally on > the back-end. I could change your rights to do something, but you > would still use the same credentials. I do not need to revoke them, > nor do you need to worry about changing credentials every time your > rights are extended/reduced/changed. >
Basically you are both thinking single granularity and single domain and centralized mandatory controls here. Lets look at these 3 issues one at a time. Granularity: When you are on your desktop PC, you are logged in under your user account. When doing acces control on a single (user) level, your word processor has the same set of authorities that the trojanized pirated game has that you happen to like playing. As a result, the game could go ahead and mail your personal and privately confidential files to the evil hacker that trojanized it. For this reason access control that works on a finer granularity level is needed to address access control. In this case at a per-program or per process level. Now look at big programs like web browsers that connect to the internet and are subject to atacks against their programming logic. In memory unsafe programming languages like C++ and in languages with many global authority and functionality like javascript, all of the programs logic, when compromized, has access to a major part of the programs authority. Again at an even finer granularity level, that of a program module level of granularity, access control would be useful so that a compromized program module would not be able to exploit other program module authority that it has no intended dependency on. A few years ago I wrote a user space file-system that hapens to work capability based that tried to be a discretionary bridge between granularities. That is, the stack AppArmor(static program level granularity)/MinorFs(Dynamic pseudo-persistent-process level granularity)/E-Language(program module granularity) was able to use some kind of capability based access controll across multiple granularity levels leading to a solid way to design high integrity systems on Ubuntu and Suse Linux systems. http://www.linuxjournal.com/magazine/minorfs Multi domain: When staying at the user level of granularity, Allan Karp wrote an excellent paper on how authorization based access control results in a more rigid, more flexible and yet also more simple model when working cross domain than any identity based access control system could ever be. http://www.hpl.hp.com/techreports/2007/HPL-2007-105.html Discretionary vs mandatory: The great thing about capability based discretionary access control compared to mandatory access control lies in the fact that you don't need to maintain a big central database that needs to be centrally administrated. Each piece of code with a given set of authorities has the ability to decompose and/or attenuate this authority and delegate the attenuated partial authority to other entities. This may not seem like a big deal when thinking about things in a user-level granularity only, when you ever tried to do the same at a finer granularity for example using and maintaining SeLinux profiles, you will likely realize what a pain central administration can be, even if there is just a single domain involved. Capability (as described here), sounds like I have a unique credential > for doing each action, almost as if the credentials identified who I > am and what I can do. > If it does, than this I hope is an error in the description. Even if a system is designed so that the user gets a single authority token that represents all his authority, than this token should basically not allow the direct invocation of the things it grants access to. Rather this token should allow for decomposition and attenuation into more fine-grained authority tokens. Maybe Dan could elaborate a bit more on decomposition and attenuation in his design. Rob -- 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
