[cap-talk] In Defense of Identities - not

[Jed at Webstart]

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/