> > 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. >
It is a nightmare even without. Having lots of credentials to manage for each app is just as burdensome as having to have a single central management system and changing and managing settings for each. > I believe OSX has added a layer of dynamic discretionary access > control http://en.wikipedia.org/wiki/File_dialog#Powerbox Cool, did not know that. The article says it was intro'ed in Lion. Is it enforced? Is this part of the sandboxing approach they are after? > 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. > That model would work really well for iOS apps. Right now, each has its own storage space. To be able to delegate total access of part of your storage space to another would be very powerful. To be fair, I have not delved too deeply into the iOS security sharing model and see what it can do right now. > > 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. > :-) > 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. > OK, so: (a) how do you manage so many keys (b) how do you have them automatically revoked? If I give her the original D+G keys, then revocation breaks mine; if I don't, then I need to create and manage *more* keys; (c) never heard of a Solex before, had to look it up! > 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. > Good point, but this is a really interesting discussion. My apologies to Dan for leading it astray. I was hoping to get a better understanding as to how and when I would use it as opposed to classic authorization, and then perhaps try it in a project and give him feedback. Got much more in depth on the principles, though. A -- 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
