> 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
Agreed, having a game with different privileges than a Word processor would make a lot of sense. The iOS model is the more extreme version: you have access to a sandbox, and that's it. You cannot get at the core operating system, or the filesystem, or even the sandbox of other apps........ But I think the reason they do that is because a real fine-grained model - allow app A to do D E but not F, app B to do D F but not E, etc. - is a nightmare to manage. I cannot imagine regular consumers managing privileges like that for each app, and so, the two real choices were the OSX/Windows model of let the app do almost everything (well, at least OSX and Unix have sudo), or let it do nothing except in its sandbox. > 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 I don't think anyone would argue for anything less than authorization. Identity-based access control really is nothing more than auth/auth with a single level of authorization: "grant all". > 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. Can you be more specific here? Do you mean that since Adam has credentials that allow him to do action D, Adam can just give them to Eve to do D, rather than go to a central database, and say, "grant rights for D to do Eve?" But then we come back to the same initial problems: - Nothing prevents Eve from then giving them to someone else. At least if Eve has her own auth credentials, unique from Adam, then Adam can be told, "this is you, don't share it, if you need Eve to do something, go to this nice Web-based interface and give her privileges." - We do not know if Adam, Eve or someone else actually did D - these things are extremely important in secure and in regulated environment. Ever dealt with HIPAA or SOX? You *must* maintain an audit trail, and *never* share credentials like that. - Management of a mess of credentials. If Adam can do A,B,C,D,E,F,G,H, he is going to manage 8 different credentials, plus his authentication? - Revocation? > 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 Can you describe further? Do you mean Adam has credentials that identify him, which he then uses to get other temporary or permanent capability credentials? -- 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
