[cap-talk] Confused Deputies in Capability Systems - not

[Jed Donnelley]

At 07:12 AM 2/26/2009, Sam Mason wrote:
>On Thu, Feb 26, 2009 at 10:28:46AM +0000, David-Sarah Hopwood wrote:
> > Sam Mason wrote:
> > > I've since realized that it's far more
> > > complicated than this and it should be checking that the source file was
> > > readable by the submitting user and the output is going somewhere that's
> > > writable to the submitting user.
> >
> > Even that wouldn't be sufficient:
> >
> >  - the compiler may not be authorized to know the information that
> >    would allow it to perform a correct access check.
> >  - performing access checks at user level introduces race conditions.
> >  - what if the client is itself a deputy? In that case the compiler's
> >    check that the client has the necessary permission would succeed,
> >    even though the access should be denied unless the client's client
> >    also had that permission. Even if (unrealistically) we assume that
> >    the compiler were trusted to perform system-level access checks,
> >    its client certainly will not be.
>
>Of those I'd only considered the race condition.  There were a couple
>of other cases that I can't remember now, hence why I said "there are
>other"s.

Such problems are legendary.

>I'm left wondering how anyone has got anything done with any level
>of robustness under IBAC.

I think part of the answer is essentially that they (we) in some
sense really don't - get anything done in terms of effective access
control.  IBAC systems like Unix and Windows generally deal with
relatively few users and with not much sharing that is sensitive -
especially between running programs.  There is essentially no effort
at least privilege computing.  Communication between mutually
suspicious parties is rare and effective controls for same even
rarer.  It's true that my bank doesn't trust me (fortunately).
To me it seems that such controls are mostly handled through the
Web these days.  Would my bank trust me as a Unix or Windows
user on their systems.  Not hardly and for good reason!!

>It all sort of seems to hang together for
>what's turned out to be the common case on most PCs, but it all seems so
>fragile and even on PCs that's changing fast.  For most server/service
>orientated workloads operating system level IBAC just seems to get in
>the way more often than it helps.

I generally agree there, though as I noted when discussing Horton
above I believe that IT systems for people will continue to need
to be able to track personal responsibility for actions at some
level.  Fortunately it seems that can be done with this object
oriented, "capability", approach to communicating authority.

>Or am I missing something? or am I
>just starting to understand the cap-talk communities' disbelief that
>IBAC is so popular.

Hard for me to say from what's been written so far.  However, I certainly
don't "disbelief" that IBAC is so popular.  I well understand the
popularity of IBAC.  As they say, "I was there.".  I was one of quite
a few who developed capability-based systems, only to see them
out competed by IBAC systems.  To me the intuitive appeal of IBAC
systems is clear.  We are people using computers, so it seem natural
to base access control decisions on the people, the "user"s.  We want
to be able to control and to know who did what.

Capability based systems were actively shunned by security professionals,
particularly those with a military (e.g. mandatory access controls)
viewpoint.  I know this is old news, but perhaps some who doubt this
haven't yet looked at:

http://www.webstart.com/jed/papers/P-1935/

TRADITIONAL CAPABILITY-BASED SYSTEMS:
AN ANALYSIS OF THEIR ABILITY TO MEET THE
TRUSTED COMPUTER SECURITY EVALUATION CRITERIA

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?

Capability-based systems can provide a lot of value, including,
famously, least privilege protections between mutually suspicious
processes.  However, to the casual IT professional they can
seem counter intuitive (perhaps until the isomorphism with
object oriented systems is clarified) and foreign (until
mechanisms for supporting identity based controls in capability-
based systems are clarified).

I still believe the best hope for capability-based systems is
in the area of access control over large networks.  This is a good
point for me to join with Bill Frantz in disputing:

>marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) on Thursday, 
>February 26, 2009 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.

in the strongest possible terms.  Not only can capabilities as data
be communicated globally without any needed registry of identities
(as with IBAC systems) as Bill notes:

>This statement is wrong on the face of it. Any data-as-capability (e.g.
>WebKeys, SPKI authorizations, etc.) can be securely passed through systems,
>such as encrypted email, that are completely unaware of capabilities, let
>alone the precise capability system they represent.

but even with capabilities as descriptors, network protocols can
be used (e.g. again capabilities as data) that can allow them to
be communicated, again in a distributed manner (e.g. along the
lines of DCCS: http://www.webstart.com/jed/papers/DCCS/
and other such mechanisms).

The capability as an "object" is much more susceptible
to wide distribution without a central control or registry
than any IBAC mechanism.  When referring to "identities"
you almost immediately have to ask about which registry
of identities.  With capabilities as general objects that
issue doesn't bite.

I'd like to say one other thing - in the form of a challenge -
about capabilities as data, but as this message is already
too long I'll put it into another post.

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