[cap-talk] Capabilities - the rub (was: NCSC TCSEC)

Jed at Webstart donnelley1 at webstart.com
Thu Nov 9 19:42:08 CST 2006

(for a briefer read, please skip down to Here's the "rub" (about
1/2 way through this message)

At 02:37 PM 11/4/2006, Valerio Bellizzomi wrote:
>On 01/11/2006, at 18.33, Jed at Webstart wrote:
> >).  I believe the concerns of the authors about capability systems
> >are pretty clear, e.g.:
> >
> >pp. 3 "merely possessing the capability ... is sufficient proof
> >that access should be granted.  Note that, if a capability is
> >ever stolen or given away, this protection mechanism can result
> >in other subjects accessing the object without incurring a
> >protection violation.  Thus, special care must be taken to
> >prevent the use of capabilities that are stolen while migrating
> >on off-line storage or among different sites of a network
> >[Nessett82, Donnelley80]"
>Comparison of "capabilities" with "badges" is apropos, a stolen badge
>doesn't incur in security violation, but it allows an unauthorized person
>to open the door. It is then a question of detecting the theft ASAP, so
>that the badge can be disabled (i.e. the capability revoked).

and the oft cited "key" metaphor also may be helpful.  To carry the badge
metaphor a bit further I think the TSEC authors want the sort of badge that
identifies a person so that any access can be associated with the
person (e.g. logged/audited) and controlled via access list.

> >I believe this document and a few others like it during this time
> >were essential in basically killing the object/capability approach
> >to computer security.  I also believe that any effort we make to
> >reverse this trend will have to answer the objections in this
> >and similar documents.
>But this is an old paper, I believe the "traditional" capability-based
>system they talk of are also old, it is possible that the *new*
>"traditional" capability-based systems are different from the old ones.

I don't believe there are any substantive differences.  The authors are
focusing on the core of the capability paradigm.  Namely the delegation
mechanism, e.g. as per a Granovetter diagram like:


>Anyway I think that the TCSEC requirement 2,
>"Requirement 2 - MARKING - Access control labels must be associated with
>objects. In order to control access to information stored in a computer,
>according to the rules of a mandatory security policy, it must be possible
>to mark every object with a label that reliably identifies the object's
>sensitivity level (e.g., classification), and/or the modes of access
>accorded those subjects who may potentially access the object."
>gives the impression that such "labels" are similar to the philosophy of
>capabilities, except that capabilities identify the object itself (not its
>sensitivity level) plus an access mode.
>A badge is similar to a label too. If a badge is similar to a capability,
>a thief can open doors with a stolen badge, but he cannot pass an human
>security control that verifies the badge visually, bacause a badge
>identifies also the person to who it is given by a photo and the name of
>the person.
>So, is it possible that the "marking" could be used as an element of a way
>out of TCSEC, and as an argument to "rebirth" the object/capability
>approach to computer security?

You didn't seem to address the term "subject" referenced in their quote.
I believe the subject notion is the key element to their concerns and
generally the issue for those who successfully oppose capability
systems in commercial applications.

Here's the "rub" (as I see it of course).  The people who think along
TCSEC lines (and they aren't just military and or government and
MLS people) think in terms of people and what they should have
access to.

Consider the recent HP board scandal (obvious leak, find the leak,
fix it).  If your IT infrastructure runs a typical identity based system
(think Unix or Windows) you remove his account.  End of problem.
You might want to know what he (it was a he in this case) did have
access to for damage control, but at least things aren't going to get
any worse.

If you run on a capability infrastructure you can remove the account,
but then you think, "Oh my gosh, I wonder where he might have
delegated access to some of the resources he had access to?"
How do I remove any access that he might have delegated?"

When David Wagner says:

At 03:20 PM 11/4/2006, David Wagner wrote:

>A personal opinion:
>The TCSEC requirements are most irrelevant to modern computer security in
>the commercial world.  They're a waste of time.  Every second you spend
>trying to comply with TCSEC is one second forever lost from your lifespan.
>They're not worth the brain cells; don't bother.

I respectfully disagree.  Perhaps if you focus on the MLS aspects of the TCSEC
we generally agree in this area.  I believe MLS, Bell and LaPadula, etc. is
pretty much a mess and likely to stay that way for some time (forever?).
Perhaps that aspect of the TCSEC can be safely ignored and considered
irrelevant for "modern computer security in the commercial world."

However, I think the base concern about binding subjects (continue to think
people for a while here) to their authorities coupled with the concern about
unrecoverable delegations continues to be relevant and remains at the heart
of why the object/capability paradigm is still considered impractical (though
there are other concerns, implementation issues, performance, usability,
etc.) in 'modern' computer systems.

In a system that uses identity based access control such as Unix, one
can look at an object (e.g. a file) and say, "Ah, I see who can access
this file.".  This user (the owner), perhaps people in this group (with this
or that access) and perhaps some access for everybody else on this
system.  I get all this information from looking at the access permissions
associated with the file.  I can directly see which subjects (users) have
which access to this object.  If I want to find out which resources some
user has access to, I can also do that fairly easily.  I just check to see
which groups this user is in and which resources are either owned by
that user, are accessible (in whichever way) by some group that user is
in, or are world accessible (in whatever way).  I seem to have the full
"access matrix" at hand.

How do I do the equivalent operations on an object/capability based system?

I guess I'll just leave that question hanging out there for a while to see if I
get responses before I weigh in on the other side of this topic.

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

More information about the cap-talk mailing list