On 27 feb, 10:32, deitch <[email protected]> wrote: > > 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.
Its a nightmare to manage with central management for mandatory access controls. I believe OSX has added a layer of dynamic discretionary access control http://en.wikipedia.org/wiki/File_dialog#Powerbox This is between user and process, but similar discretionary access controls are possible between programs. Let me revisit my own pet project MinorFS. Here a process is delegated a private directory that if it wants can keep it all to itself. It can however also take a sub-tree of this directory and delegate it to an other process. If that other process is written in a capability secure language, a file from this sub-directory can be delegated to a program module while all other program modules in the same program are denied access to that same file. Basically delegation makes dynamic fine grained access control manageable, and capabilities are a good fit for enabling and promoting delegation. > > 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". Its not fully 'that' bad, but for many practical purposes its indeed almost as bad. > > 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? Basically if Adam can do A,B,C,D,E,F,G,H and wants Eve to be able to do D, than Adam can give Eve a capability to an attenuation proxy to D. Its like having a big key-ring with multiple copies of A,B,C,D,E,F,G,H keys on it but with the magic property that Adam can give the key to his shed D and the key for his solex G to Eve, ask Eve to go and put his solex in the shed and than after Eve parked his solex in the shed automatically have both keys revoked so Eve no longer has access to either the solex or the shed. All a matter of creatively defining the right often short lived attenuation proxies. Now try to imagine doing something like that with a centraly managed SELinux style mandatory access control system. > > 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? Its like your earlier example, Adam could have capabilities for A,B,C,D,E,F,G,H in a big bag of capabilities. In order to invoke E, Adam should use his E capability, not anything more, unless invocation of E requires E to get a (temporary) right to invoke an other capability. Lets say that Eve from our earlier example herself is capability based ;-) We could than do something like: solexProxy = new Caretaker(Solex); shedProxy = new Caretaker(Shed); Eve->goPark(solexProxy->cap(),shedProxy->cap()); solexProxy->revoke(); shedProxy->revoke(); Its a bit of a simplified and contrived example but I trust that you get the general point. B.t.w. I believe this discussion is drifting off quite a bit from Dan's original request for feedback. Instead of arguing the merits of capability based access control, I think we should take these as a given (or discuss them somewhere else, for example on the cap-talk mailing-list) and try to keep this tread about Dan's specific proposal on how well a fit his web capabilities for NodeJs/browsers are. I hope Dan does not exclusively think of his proposal as a frontend/ back-end kind of thing, as I believe most of the power of capabilities would arrive from creating capability systems that could span a multitude of NodeJs instances. -- 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
