[cap-talk] Capabilities - the rub, ACL management

[Jed Donnelley]

At 05:22 PM 12/8/2006, David Hopwood wrote:
>John McCabe-Dansted wrote:
> > On 11/23/06, Marc Stiegler <marcs at skyhunter.com> wrote:
> >>
> >>John McCabe-Dansted wrote:
> >>
> >>>>Indeed, you have made an assumption about functionality in acl systems
> >>>>that is not present in any popular acl implementation. It is not
> >>>>possible for the holder of a read authority to delegate that read
> >>>>authority to another person using the acl system. Only proxying as I
> >>>>described earlier is possible. Why? Because for me to give Sarah an
> >>>>explicit read permission, I must have acl-entry-editing permission. If I
> >>>
> >>>In practice this is commonly achieved by asking the sysadmin to give
> >>>Sarah your access. Although this habit has considerable overhead, it
> >>>also has some advantages as the sysadmin should be aware of the
> >>>security implications of delegating certain rights and advise the user
> >>>as to which exact rights they want to delegate. This would also allow
> >>>us to find out who misused the right, either directly or indirectly by
> >>>setting up a proxy in violation of company policy.
> >>
> >>"Considerable overhead", oh, lordy, yes.
> >
> > Editing an ACL takes less than a minute.
>
>If it takes 30 seconds, say, that's far too long. Compare it to 
>using a powerbox
>to delegate permission to access a file, which takes *zero* extra 
>time relative
>to what would be needed to designate the file in any case.

While I agree that 30 seconds is way too much, I think that also
way understates the difficulties with ACLs.  The issue of who
or what has permission to modify an ACL has been discussed, but
of course it is critical.  If I have to go through a systems
administrator to get an ACL updated (as effectively happens
in Unix systems often - I know, I'm on the receiving end)
then of course appropriate delegations may take hours
or many days.  This is so bad that users frequently resort to
other means (e.g. sharing accounts) to get around the
restrictions.

If you have a system in which any identity with a permission
has the right to share it, then you can in principle automate
delegation to some extent.  In that case you have something
more like a capability system, but it's still worse in some
ways.  For example, if I am a confined process in a capability
system I can't share my permission outside that confinement
(the appropriate way to block delegations as you block data
flow in an object/capability system).  However, in an ACL
system if I can modify an ACL I can delegate a permission even
if I can't communicate to the recipient.  Blocking communication
doesn't solve the problem.

I really feel the ACL model is broken.  Anybody who tries to
run an SELinux system with any amount of sharing on it well
knows this.  I tried to work with it but ultimately had to
just disable it in all my systems.  If you aren't doing too
much sharing of course ACL systems can function.  In that
case there really is no delegation to speak of, so the ACLs
really aren't used.  If you put some dynamic demand for sharing
on such a system, the sysadmin becomes so much of a bottleneck
that something has to give.  That's my experience in any case.
I'll be interested to hear from folks for whom ACL systems
have worked well.  I'm particularly interested to know who
does the ACL management for whom.

--Jed  http://www.webstart.com/jed-signature.html