[cap-talk] In Defense of Identities - not

Wed Dec 6 10:45:39 CST 2006

Jed wrote:
> 
> At HP last Friday I mentioned a facility that we had at LLNL many
> years ago that I considered quite helpful/useful in bootstrapping
> sharing between people.  It had the following properties (sorry if
> this is a repeat - I see it as relevant here):
> 
What Jed goes on to describe is very similar to the Client Utility Name
Frame mechanism.  Details on request.
> 
> The features that the above system didn't have that seem
> to me can provide additional value are responsibility tracking
> and revocation.
> 
Client Utility did have both, but responsibility tracking was done by
auditing in the Core, the component which mediated all interactions.
> 
> That's the argument that I'm making also and I'm making a
> concrete suggestion.  Please tell us Jonathan if there's something
> still missing in the proposed responsibility (with 
> revocation) tracking
> mechanism that you feel is needed, and if so what else do you feel
> is needed and why.

The main issue I see is the inability of Alice to delegate to Bob a
responsibility-tracked capability right to use Carol without involving
Carol.  I think that's unavoidable.
> 
> Also I'd like to understand how you imagine an IBAC mechanism
> to work.  That is, if you don't imagine the identities themselves
> being able to delegate their permissions, who do you imagine being
> able to do so?  How do you see that working?
> 
I don't.  It is my contention that IBAC is unworkable.  It is only by
enormous effort that we get it to work at all within a single machine or
administrative domain.  IBAC doesn't work at all when crossing
organizational boundaries.
> 
> I suppose I should mention that I don't have any problem with using
> an ACL mechanism to implement permissions that can be delegated
> (what I call a 'capability', but never mind).  I mentioned in:
> 
> http://www.webstart.com/jed/papers/Managing-Domains/#s10
> 
> two such mechanisms (ACL and "encrypted address") that one could
> call "identity" variations.  Those protocols used ACL mechanisms for
> their implementation, but the key is that they were used to implement
> what effectively amount to 'capability' semantics. 

This mechanism is very similar to the proposed Client Utility
introduction protocol.  The only difference is that we kept a c-list
instead of an ACL.  Details on request.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed 
> at Webstart
> Sent: Tuesday, December 05, 2006 4:53 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] In Defense of Identities - not
> 
> At 10:12 AM 12/5/2006, Karp, Alan H wrote:
> >Jonathan S. Shapiro wrote:
> >...
> > > Once we acknowledge that this is a discussion about 
> relative costs, it
> > > may be the case that the technical deficiencies of identity-based
> > > authorization are real but irrelevant. The nuisance 
> factor of ACLs may
> > > actually be at just about the right level.
> > >
> >I contend that the nuisance factor of ACLs is far higher than most
> >people acknowledge.  That squeaky door that drove you nuts when you
> >first moved into your house, you don't even notice a month later.  We
> >have become so used to dealing with the difficulties of ACLs 
> that we no
> >longer realize what a high cost we are paying.
> 
> Oh my gosh, amen to that!!  I happen to be in the loop (as a sysadmin)
> when people try to apply the ACL approach to access control.  
> The basic
> problem with an ACL approach is the question of who controls the
> ACL?  If only a sysadmin can do the work then any effective sharing
> effectively grinds to a halt.  It's also of course subject to the
> "fatal conceit" that Marc Stiegler mentioned.  Why is it that as
> a system admin. anybody would get the impression that I would
> have a better idea how to delegate access than somebody who
> was actually delegated the permission (rather than just having it as
> some sort of superuser status) and has local knowledge (e.g. was
> told policies or whatever regarding how to exercise the permission)?
> 
> The only reason an approach like that used in Unix (e.g. groups)
> even begins to work (at least in our environment - I'll be interested
> to hear from others in this regard) is that resource owners can enable
> group access or world access without the need to get a sysadmin
> involved.  If there are reasonable groups available then delegation to
> at least the granularity of a group is possible by the resource
> owner.  As Mark Stiegler points out, in reality most sharing is done
> through the network, usually by repeated (if necessary) copying.
> How much access control is that?
> 
> Alan Karp is exactly right.  The current dominant scheme is
> almost totally broken.  It's been around so long and we've
> learned to work around it and become relatively comfortable
> doing so for so long that most of us don't realize just how much
> of a barrier to collaboration the current IBAC mechanisms are.
> 
> At HP last Friday I mentioned a facility that we had at LLNL many
> years ago that I considered quite helpful/useful in bootstrapping
> sharing between people.  It had the following properties (sorry if
> this is a repeat - I see it as relevant here):
> 
> 1.  Anybody could make a directory (in which to store other
> directories or files - all that system dealt with).  If they did
> so then initially only they had permission to access it (a
> 'capability').  If a person (user) has access to a directory
> they can access the permissions in it (named permissions
> to files and/or other directories).  I expect you can imagine
> how RW (forget X) worked for such directories, but I could
> describe more detail if it's relevant.  This system effectively
> creates a directed graph of access control - though without
> the provisions below there could be no sharing between users.
> 
> 2.  Every person (user) could grant access to any directory or
> file that they can access to any other user.  Every user had
> what might be called a "gift" directory.  I could insert
> objects into your "gift" directory as long as there wasn't
> a name conflict.  You could move (or remove) objects from
> your "gift" directory and put them anywhere you liked.
> (note, such gifts weren't labeled as to where they came from).
> 
> 3.  Every user could effectively post permissions (access to
> a file or directory) for global consumption.  I can look in the
> global directory for your name and see if you've posted
> anything for global consumption (e.g. our equivalent of
> "open source" worked that way).
> 
> [incidentally, the above system had MLS (at LLNL how could it
> not?), but the MLS mechanisms were so broken and unusable
> that they generally weren't used].
> 
> This system worked terrifically.  It was all user managed and
> no sysadmins had to get involved.  If I want to start a group
> collaboration I can create a new project directory out of
> whole cloth and give the members of the group permission
> to access it.  Each initial member can of course give others
> access.  If you consider that a "rub" (as I do), read on.
> 
> The features that the above system didn't have that seem
> to me can provide additional value are responsibility tracking
> and revocation.
> 
> Suppose that in addition to the above whenever a permission
> was delegated (either by being given or by being taken from
> a global post) it was labeled as to who it came from and who
> received it.  Also suppose that the person who delegated it could
> revoke it but could not access the delegated permission (couldn't
> pretend to act as the person the permission was delegated to, (e.g.
> 
> Tyler could access the Tyler permission, but only
> Bob could access the Tyler -> Bob permission [at least initially]).
> 
> To me that sounds like a very powerful paradigm that can lead
> to useful sharing without need of sysadmin involvement (or any
> other form of "fatal conceit") while at the same time providing
> very strong responsibility tracking (including logging) and controlled
> revocation.
> 
> > > Even if Trent acts as you say, the fact that Trent must authorize
> > > becomes auditable -- which may be the entire value 
> obtained from the
> > > sequence.
> > >
> >If all you want is audit, there are easier ways.
> > >
> > > I confess that I am disturbed by my own direction here. I am,
> > > in effect,
> > > arguing that sophisticated conspiracy is unavoidable but rare,
> > > unsophisticated conspiracy is common but traceable, and 
> that the right
> > > level-set may therefore be to provide mechanisms that 
> guard against
> > > unsophisticated conspiracy and oblivious error.
> > >
> >I contend there are better ways to achieve your goal than introducing
> >ACLs.
> 
> That's the argument that I'm making also and I'm making a
> concrete suggestion.  Please tell us Jonathan if there's something
> still missing in the proposed responsibility (with 
> revocation) tracking
> mechanism that you feel is needed, and if so what else do you feel
> is needed and why.
> 
> Also I'd like to understand how you imagine an IBAC mechanism
> to work.  That is, if you don't imagine the identities themselves
> being able to delegate their permissions, who do you imagine being
> able to do so?  How do you see that working?
> 
> I suppose I should mention that I don't have any problem with using
> an ACL mechanism to implement permissions that can be delegated
> (what I call a 'capability', but never mind).  I mentioned in:
> 
> http://www.webstart.com/jed/papers/Managing-Domains/#s10
> 
> two such mechanisms (ACL and "encrypted address") that one could
> call "identity" variations.  Those protocols used ACL mechanisms for
> their implementation, but the key is that they were used to implement
> what effectively amount to 'capability' semantics.  That is if I am an
> identity (I referred to as being in a 'domain') with a 
> permission, then I can
> grant that permission to any other identity with whom I can 
> communicate.
> There's a little handshake (that must be done with some care to avoid
> confused deputy problems) for the ACL case, but it can be done.
> Alice can effectively say, "Hey Carol.  I'm on your ACL for 
> this object.
> Please put Bob on the ACL for me."  Then Alice has to be able to
> communicate to Bob that it was she who added him to the ACL
> (a small but important angle on a confused deputy).
> 
> Requiring a "superuser" to get involved in every delegation simply
> cannot work.  That approach really is subject to the complexity
> problems that Lampson rightfully (while wrongfully pointing at POLA)
> denigrates.  Even an owner based approach (having a distinguished
> 'owner' for every object that is responsible for managing the ACL)
> can't work effectively IMO.
> 
> I argue that the 'capability' approach (those with access 
> being enabled
> to delegate it to those with whom they can communicate) is not only
> the only thing that can be enforced (in the 'theoretical' 
> sense), but it
> is the only sort of approach that can work in the very practical sense
> of dealing effectively with local knowledge/control and 
> having a system
> with manageable bureaucracy.   If you add in identity tracking for
> delegation (not for access control except to include 
> revocation) then I
> believe you get all the auditing and control that can be 
> expected of any
> ACL system in a workable package.
> 
> That's my story.  I wish we'd all been in that meeting room 
> last Friday
> at HP.
> 
> --Jed http://www.webstart.com/jed/  
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 