[cap-talk] Examples where ACLs are a better solution than capabilities

[Mark Miller]

On 10/7/07, Jed Donnelley <capability at webstart.com> wrote:
> At 04:00 AM 10/7/2007, Jonathan S. Shapiro wrote:
>
> >... but I actually do agree that there are
> >places where ACLs are a better solution (I can hear the cries of
> >"heresy" ramping up already).
>
> I seem to remember this discussion once before.  However, I think
> at least a reminder would be helpful in this case.  Can you please
> describe a place or two where ACLs are preferable to capabilities
> for access control Jonathan?

Here's one I've been thinking about lately:

Say you have a large installed base of technology, infrastructure,
thinking, habits, superstition, process, emergency response teams,
etc, all built up around ACLs. Say you want to see this whole system
of people and software eventually switch to capabilities. Compare two
strategies:

1) You say: "To get the benefits of capabilities, you must stop using
ACLs. Write off all those sunk costs. They're wasted anyway. Stop
throwing good bits after bad ones."
"But how do we know we'll be safe in this untried brave new world you offer?"
"<complex answers rooted in theory and history, both of which needs
unusual interpretation>"
"How do we maintain our safety during the switch from ACLs to capabilities?"
"<??>"

2) You say: "Your ACL systems aren't providing adequate safety. To
gain the benefits of capabilities, phase them in as additional checks
that must be passed. Over time, if you see that most of your safety
comes only from the capability checks, then you can phase out the ACL
restrictions. If you're not satisfied that capabilities by themselves
are better, you can keep your ACL checks."

The result of strategy #2, if successful, will be messier than the
results of strategy #1, if successful. If we're confident that both
strategies would succeed, we should chose #1. But...

Remember that attempts to get C programmers switch directly from C to
objects repeatedly failed. What succeeded instead took two steps: a)
Getting C programmers to use objects in addition to C, making C++. b)
Relieving C++ programmers of the bone crushing complexity of C++, by
removing from it the C crap, making Java.

In other words

      The other 90% of the work is always migration strategy


> >Hmm. Taken together, your two statements seem to imply that a
> >two-mechanism system might be worthwhile. If so, I suggest that it must
> >be a logical AND rather than a logical OR. That is: if both ACLs and
> >capabilities are used, BOTH must permit the operation in question in
> >order for the operation to proceed.
> >
> >The problem with either-or systems is that things slip through the
> >cracks where (a) the two systems have been configured in subtly
> >different ways, or (b) the overlap in what the two systems can express
> >is imperfect.
>
> I think I'm starting to get sick.  I believe we have evidence of
> reasonably successful ACL systems and reasonably successful
> capability systems, but I know of no even moderately successful
> mixed systems.  Perhaps MarkM can help us out here with some
> examples that successfully occupy this space?

This kind of ANDing of cap and ACL rules is known in the literature as
a "hybrid capability system".

The system that's been cited on the list as the biggest success for
capabilities is the IBM System/38 aka AS/400. It is in fact a hybrid
cap system. More specifically, it has two forms of capabilities: 1)
so-called "authorized capabilities", which are true
object-capabilities in our sense, and are adequate by themselves to
permit access. 2) so-called "unauthorized capabilities" which
authorize access only when combined with an ACL check.

Other hybrid cap systems in the literature, whether or not actually implemented:
* Karger & Herbert's SCAP system
* Li Gong's ICAP
* Most of the taxonomy in the Kain & Landwehr paper
* SPKI, depending on how you look at it
* Alan's Client Utility, again, depending on how you look at it.

I know there were several more, but I can't recall them at the moment.
It's an idea that keeps getting reinvented to repair mythical problems
of capability systems.


> Of course one of the main points of Horton was to demonstrate
> that we can achieve the main values of ACL systems with pure
> capabilities.  Presumably then the examples where ACL systems
> are a better solution go beyond what a mechanism like Horton
> can supply.

Horton can't supply the comforting reassurance that all the money you
spent on ACL infrastructure wasn't wasted.


> Seems like a good topic for cap-talk - unless we have been over
> these examples before.

I think this is an excellent topic for cap-talk. We have not spent
much time in the past talking about hybrid capability systems. And I
don't recall that we've spent any time talking about them as a
migration strategy.

I've been increasingly thinking about Horton as a way to model (an
idealization of) hybrid capability systems in pure capability terms,
so that we can at least try to understand the mess we'd be getting
into.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM