[cap-talk] Capabilities are broken (was: Re: The TCSEC influence on computer security/systems (was: Re: Horton at HotSec...))

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Wed, 2007-07-11 at 12:32 -0700, Jed Donnelley wrote:
>
>   
>> The Trusted Computer Security Evaluation Criteria was the only
>> credible computer
>> security evaluation criteria of the time.  The community (DOD, etc.)
>> that were pushing
>> these criteria were viewed at the time as having considerable market
>> clout and were
>> taken very seriously.  In a sense they were the only game in town.
>>
>> If instead of that document...
>>     
>
> As a side note on that document, I have a memory that it was the first
> step that let Susan Rajunas to do her MLS design for KeyKOS. Susan was a
> well-regarded player in the TCSEC effort, and disagreed with Gligor and
> others on this subject very strongly.
>   
From:

Traditional Capability-Based Systems: An Analysis of
Their Ability to Meet the Trusted Computer Security
Evaluation Criteria - a scan of which can be found at:

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

___________
We wish to acknowledge the assistance of Dan Nessett, Lawrence Livermore 
Labs; Richard Kain,
University of Minnesota; Norman Hardy, Susan Rajunas, et. al., of 
Keylogic, Inc.; and
Roger Schell of Gemini Computers, Inc., for their thorough review and 
critique of the
initial drafts of this paper.  Their comments helped significantly in 
providing better focus
and presentation of the material.  The authors, however, remain 
responsible far the
accuracy and appropriateness of the contents of this final version.
___________

The above gives the impression (perhaps intentionally?) that Norman and 
Susan agreed
with the conclusions of the paper.  There is nothing in the paper 
regarding anything like
a dissenting minority opinion.  The paper gives the impression that it's 
conclusions are
quite clear and obvious and that the only hope for any sort of a 
"capability" mechanism
to meet the Trusted Computer Security Evaluation Criteria would be for 
it to be so
modified beyond the "Traditional Capability-Based Systems" as to be 
nearly unrecognizable
as a capability-based system.

Allowing ordinary user processes to directly communicate permissions 
when they
can otherwise communicate is just way to uncontrolled for the authors 
and the
community that they represented and for that community today.

This is the fundamental issue that we have to address if we hope to use
anything like object/capabilities to achieve something closer to POLA.

Just consider these two quotes from the paper:
_________________________________

pp. 26 "2.3.1 Security Policies

> In traditional capability systems, capabilities are freely
> copyable and can be placed in any storage object In the tagged
> memory approach, capabilities can be intermixed with
> the data of storage object and in the partition approach, 
> capabilities can be stored in the C-list of the storage objects.
> This flexibility, although advantageous in  many ways, causes
> several important security policy and object management problems.
> In fact, these problems are so great that traditional capability
> systems are unable to  support any mandatory security
> policies without extensions or basic modifications.

________________________________

You have to get past the technical details that they
mention about tagged memory and capabilities intermixed
with data.  At a fundamental level they are objecting
to the basic capability paradigm of being able to
communicate an object reference (capability) in a
message.  As they go on further to say (NOTE!):
________________________________

> Discretionary security policies are based on the notion that
> access  privileges for an object may only be changed by the
> *owner (creator)* of that object [Saltzer75]. The three
> important components of such policies are: (1) the
> distribution, (2)  the review, and (3) the revocation of
> access privileges. Note that the discretionary policies 
> may allow an owner to entrust the authority of further
> distribution and/or revocation of privileges to other
> parties at his discretion.

________________________________

If you accept that capability systems can't support
mandatory access controls (because they allow
uncontrolled communication of permissions where
communication is permitted) and you accept that
discretionary security policies must be based on
the notion that access permissions can only be
changed by the *owner (creator)* of that object ...
(which means that the object/capability paradigm
is in basic opposition to this aspect of
discretionary access controls that they see
as fundamental, because it allows any active
object - not necessarily representing the 'owner' -
with a reference to another object to communicate
it ...)

then what is left?  Capabilities can't do mandatory
access controls and they can't do discretionary
access controls.  That's it.  End of story.  They
can't do computer security.


I believe these issues are as pertinent today as
they were then.  This is where the fundamental
opposition to the object/capability paradigm comes
from.  It isn't a narrow issue like whether one
can do MLS in what this defense community would
regard as an impractical sense or whether one
can institute revocation for some communicated
permissions.  They view the basic essence of
the object/capability paradigm, the ability to
communicate permissions as object reference
parameters, as fundamentally broken.

I believe that until we address that issue head
on we have no hope of swaying this large and
influential community.

While I believe technology like Horton can help
(introduce the notion of identities with tracked
responsibility for permissions), until the basic
issue of communicating conspirators is appreciated
(that neither capability system nor 'user' based
systems can deny), I don't see any way to make
progress in this area.

Once we give up trying to block communicating
conspirators, then it seems to me that the
object/capability starts to shine through as
a huge win.  If you can't block communicating
conspirators anyway, at least you can use POLA
to insure that there is as little communication
as possible between potential conspirators and
generally as little permissions of any sort for
those very programs that we want to keep out of
control.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070712/be8ed93b/attachment-0001.html