[cap-talk] Horton vs. ACLs (was: Examples where ACLs are better...)
Jed Donnelley
capability at webstart.com
Mon Oct 8 12:52:09 EDT 2007
At 11:10 PM 10/7/2007, Mark Miller wrote:
>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:
>
>...
>
>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
While I appreciate the example and discussion, I don't see how the
above fits into a "a place or two where ACLs are preferable to capabilities
for access control..."
> > >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.
Is an "unauthorized capability" any more than a name/designation?
I guess the difference is that you really need it and can't get it
through a data path?
I'd be interested to understand how the value sought by such a
system compares to what ocaps + Horton can provide (tied into
the answer to Shap's question about whether Horton could be used
for "OS style" capabilities).
>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.
Are there more "mythical" problems than what amount to the
communicating conspirators problem? Sorry to abuse you like this
MarkM, but I certainly value your accumulated reading on these
topics that would take me more time than I have for such reading
to approach.
> > 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.
Hmmm. I have to admit that particular value doesn't add much
for me.
> > 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.
What I was referring to was Jonathan's concern that the Horton
mechanism which I believe does qualify as a 'membrane approach'
has "...storage allocation and transitivity issues that were very
difficult to resolve without GC."
Do you know what he means there?
>We have not spent
>much time in the past talking about hybrid capability systems.
Just as well in my opinion unless there is a contingent that
feels there is genuine promise in the hybrid area. I currently
don't (as noted in rather colorful language), but will of course
be happy to contribute my thoughts to any discussion in that area.
>And I
>don't recall that we've spent any time talking about them as a
>migration strategy.
Gulp. We certainly have spoken a good deal about migration
strategies, but not as you say any that make use of hybrid
capability systems. As I've often noted, my best hope for
a transition is to get into place any compelling object/capability
system (e.g. my main current hope in the network area, CapDoc
or CapBrowser or ... WebCaps or ... Wideword+ ... all loose
terms at this point) that will then spread to other areas.
>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.
Aside from any use Horton sorts of mechanisms may have in modeling
hybrid systems, I would like to better understand the concerns that
Jonathan is expressing about the unsuitability of Horton to
practically achieve the auditability value of ACL systems
in a pure object capability context - as I believe we have
claimed in the Horton paper.
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list