[cap-talk] Core of IBAC dominance - direction? (was: Re: Confused Deputies in Capability Systems - not)

Jed Donnelley capability at webstart.com
Sun Mar 1 20:51:42 EST 2009

At 06:58 AM 2/28/2009, David-Sarah Hopwood wrote:
>Jed Donnelley wrote:
> > 
> <http://www.webstart.com/jed/papers/P-1935/>http://www.webstart.com/jed/papers/P-1935/
> >
> >
> > that concludes, in a very learned way, that capability-based systems
> > simply cannot do the (secure access control) job.
> >
> > Many of us believe that the above analysis was flawed in some
> > areas and just wrong in others.  In the area of auditing the
> > Horton mechanism is a demonstration that capability-based
> > systems can provide the auditing value that the authors
> > of the above paper claim they can't.  However, Horton was
> > 2007.  It took that long to show that something as fundamental
> > as auditing (who did what) could be done with capability-based
> > systems?
>I think this is slightly missing the point. IBAC systems did not
>support the TCSEC criteria any better than capability systems did.
>Capability systems failed to become popular by bad luck and insufficient
>marketing; any formal argument about their expressiveness, flawed
>or otherwise, played only a minor role as far as I can see. The above
>tech report was published in 1987, too late to have had a significant
>effect on the popularity of capabilities relative to IBAC.

I agree that the above P-1935 report was published at a time when
the popularity of capability-based systems had already declined to
a negligible level.  To me the significance of that report is more
in reflecting the dominant view of the time (and I argue below, this
time) and in providing an academic summary/justification for the move
away from capability-based systems.

However, when you say, "IBAC systems did not support the TCSEC criteria
any better than capability systems did." I don't agree.

I won't worry much about the TCSEC criteria per se.  As we've often
discussed on this list I believe those criteria (particularly with
regard to "Mandatory Access Controls") are not particularly relevant
in today's IT environment.

While I disagree somewhat with this view of the history:

>In any case, once Unix and VMS used IBAC and were comparatively
>successful for reasons that had nothing to do with security, it was
>very difficult for systems not compatible with them to compete.

I'd like to focus on the current state of things, because I believe
the primary reasons that people find for preferring IBAC systems
over capability systems is the same now as it was then:

I believe IBAC systems are more intuitive for people.  They directly

1.  Who is allowed to do what, in records that are easy to view,

and they can audit/log

2.  Who did what.

All active agents act on behalf of a "user" - intuitively a person.

In capability systems on the other hand, when a process acting on
behalf of Alice sends a message to a process acting on behalf of
Bob and the message contains a capability, then after receiving
the message Bob's process can access the resource designated by
the capability with whatever authorization the capability provides.

There is no way that an administrator or user can keep Bob from
accessing the object.  No way to stop the communication of the
capability from Alice to Bob, other than by blocking communication
between Alice and Bob (rather unusual in our network rich environment).

Of course we well know that if Alice and Bob can communicate and
Alice wishes Bob to have access to a resource that Alice can
access via some IBAC controls in place, then Alice can act as a
proxy for Bob and thus allow Bob access.  While such proxying is
possible in IBAC systems, it is outside the norm.  Such proxying
is made deliberately difficult/awkward to do.  An attacker can
only do such proxying for resources that the attacker already has
access to.  Any such access can be logged and audited and later
such access can be removed from the "attacker" - which was only
giving out unauthorized access, not obtaining unauthorized access.

We also know that one can add IBAC sorts of mechanisms to
capability systems like Horton.  Such mechanism are, however,
just add-ons.  They don't represent the core paradigm for
capability access control.

To me it seems to be mostly the above issues that make IBAC
systems feel more natural and effective from the perspective
of access control.  I believe it's the above issues that lead
to IBAC systems becoming dominant in the 1970s and 1980s and
coasting through most of the 1990s essentially unopposed.
Those issues were at the core of the capability criticisms
in P-1935 (ignoring the MAC stuff).

On the plus side for capability systems has always been the ability
to do principle of least authority controls.  This is generally
recognized as a value, though it's also typically thought to only
be important in relatively obscure cases.  In those cases even IBAC
systems can be bent to the purpose (e.g. create a pseudo user
for each process - as often happens these days).  Problems like
Confused Deputies are so obscure that they're only discussed on
lists like this one and even then we often can't distinguish between
those issues related to the separation between designation and
authorization (which can be solved by using capabilities for
authorization) and more general Trojan Horse problems (which
can only be indirectly helped with capability communication by
minimizing the authority of running programs).

In recent years the growing realization of the apparent isomorphism
between object oriented language systems and capability systems
has lent additional cachet and some functional advantages to
capability systems.  Others know better than I how much practical
value this has added.

To me it has always seemed (going back to DCCS) that the independence
from a central registry that the object oriented "capability" systems
provide would be a particular value as networks became more
interconnected.  Capabilities like those for Wideword and YURLs/Web keys
require no central registry - e.g. as with IDs for IBAC controls.
That's why I jumped so quickly on the comment by Marcus Brinkmann:
At 08:36 AM 2/26/2009, Marcus Brinkmann wrote:
Capabilities can only survive in an isolated, homogeneous environment.  I
think that this is a serious limitation, which in my opinion severely
restricts the applicability of capability theory.

Of course, it is possible to be more or less optimistic about the reach of a
particular capability regime.  My personal estimation is that the safe bubbles
within you can enforce a single capability regime are overall pretty small,
roughly the size of a single application.

In any case, unless you believe that all interacting systems can be subjected
to the same (world-wide?) capability system,

because it seems to me exactly opposite to one of my core beliefs.

(Incidentally, I note that my old favorite Wideword capabilities
such as: https://wideword.net/doc/JB0FrMOKuYmTM%2F3jDMTP0w%3D%3D/update
no longer function, though Wideword does seem to still be
providing service to what is perhaps a new generation of capabilities?
Hmmm.  I notice that Wideword has moved to more of an IBAC
model.  Perhaps that would be an interesting topic for a follow-up).

What I haven't yet seen for such network capabilities as data is a
mechanism for making the objects they point to available as
semantically equivalent objects in existing systems, e.g. Unix
and/or Windows.  As perhaps with a mechanism to "mount" a
networked directory capability with the ability to inject (import?)
such files and/or directories into a local structure - providing
the ability to apply local tools to them (e.g. players for
viewing, editors for file manipulation, listing for directories,
etc.).  It seems that effective caching and locking would be needed.
Of course there would be (are?  Are there such mechanisms available?)
conflicts in the area of access control, but that's to be expected
without agreement on IDs.

Can anybody point me to such existing facilities - e.g. for
YURLs/Web Keys?

--Jed  http://www.webstart.com/jed-signature.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090301/f85bae7e/attachment.html 

More information about the cap-talk mailing list