[cap-talk] What does the [defense?] security community really fear from capabilities? (was: Support of MLS policies (was Re: NLTSS))

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Thu, 2007-07-12 at 16:20 +0200, Pierre THIERRY wrote:
>   
>> Scribit Jed Donnelley dies 11/07/2007 hora 16:52:
>>     
>>> However, at the time vendors were working hard on supporting MLS
>>> policies and it was widely believed that support for such facilities
>>> would be available in those commercially available systems
>>>       
>> If I understand correctly, to summarize, caps were disregarded because
>> they had been considered unable to support MLS policies in favour of ACL
>> systems, which at that time did not support MLS policies yet.
>>     
>
> Not quite. Caps were disregarded because it was believed that they were
> unable **in principle** to support MLS.
>   
The above is a considerable over simplification.  If you read:

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/

you will get quite a clear idea of why the defense community (and with
it the general IT security community of the time) felt so strongly that
capabilities were the wrong way to go for computer security.  I don't
think the opinions of the relevant people in this community have
significantly changed - though of course the people have changed.

If you're serious about understanding this topic I strongly recommend
reading that paper.  If you're not quite that serious (it is an evenings
reading) you might take a look at my notes on that paper to this
list (if you haven't already):

http://www.eros-os.org/pipermail/cap-talk/2006-November/005815.html
and in follow-on discussion such as:
http://www.eros-os.org/pipermail/cap-talk/2006-November/005910.html

To summarize in a few short words, that community felt that capabilities
were too laissez faire, out of control.  If you consider this concern just
briefly it's easy to understand their worry and why that worry is still
relevant in the community.  We know that a capability is a communicable
permission token.  If A can communicate to B (hopefully via an existing
capability) and A has capability cap then A can send cap to B so that
if B didn't previously have cap it now does.  There is now a new entry
in the access matrix.

Are you kidding me?  This is a DOD security manager's worse nightmare.
A running program can just send such a permission?  What about the
controls, the policies, the audits?!?  Are you telling me that I've 
completely
lost control and it's the programs that are in control??!?  No F*%&ing
way am I going to accept any paradigm like that!

That is why the defense community and with it the computer security
community of the time (and still to this day) rejected capabilities (and
still do).

The MLS/MAC case was really just one instance of this concern.
Their horror of the capability paradigm went much deeper than that.
You can see it throughout the above paper regarding their evaluation
of the capability paradigm against the "Trusted Computer Security
Evaluation Criteria".  They try to keep at least the appearance of being
even handed, but you can sense throughout that document that they
don't believe any object/capability based system ever did or even could
come close to meeting the TCSEC.  Capabilities are just way (!) too
out of control.

>   
>> Did any ACL system ever supported MLS policies after that?
>>     
>
> Yes. Several. The Wang/XTS Stop system, the Multics system, Trusted
> Xenix, others.
>
>   
>> Does any
>> ACL system still in use now support them?
>>     
>
> Yes, though none at the level of assurance achieved by the three I named
> above. Primary example would probably be Trusted Solaris.
>
>   
>>  What systems do the military
>> use currently (or any other community highly concerned by security)?
>>     
>
> As I understand matters, they were forced into single-level OS's
> supported by multilevel networks. At the moment, its basically "one
> machine, one compartment", and the network infrastructure implements
> distributed compartments. Where this is not feasible, everything runs
> "system high".
>   
I can only really speak with any direct knowledge for Lawrence Livermore 
National
Laboratory (DOE weapons laboratory).  There the situation is about as 
Jonathan
describes above.  They run system high with an air gap.  There are 
classified systems
and unclassified systems/networks and never the twain shall meet.  After 
NLTSS was
retired in 1995 there was some effort put in to using the MLS mechanisms 
that Cray
made available for a time in Unicos (Cray Unix), but as I understand 
things that was
rather quickly abandoned and there is no significant production use of 
any MLS
protections at LLNL at this time.  They still classify documents/files, 
but those labels
are not provided any support by the operating systems or networks.

I believe at least the other DOE weapons Labs (Los Alamos and Scandia 
and likely
Oak Ridge) work the same, but I don't have any direct information about 
them.

As I say though, the MLS issue is really just a side light to that 
abhorrence by the
computer security people in the defense community with capabilities.  As 
Jonathan
noted, it was the issue they tried to justify their concerns with for a 
time, but when
that one got shot down, they picked another.

Despite my support for POLA and the use of object/capabilities as the 
most effective
means to that end, I strongly sympathize with their position.  It's 
partly for that reason
I feel that if we can get some of them to consider Horton, they might 
see a glimmer of
hope.  They also would very much like to get to POLA.  They just don't 
want to lose
control in doing so.

With it's disciplined delegation mechanism that includes what one might 
consider
administrative control by identity and also with the potential for 
logging/auditing,
it seems to me that Horton would hold some appeal for that community.

I really think the most fundamental issue is that of communicating 
conspirators.
That community really hasn't come to grips with the fact that the only 
way to
block (control) communication of a permission (an access right) is to block
communication.  That access control and confinement are intimately entwined.
That if there is two way communication between A and B then A and B can
share access rights.

I referred to this as the "inalienable right" to communicate permissions in:

http://www.webstart.com/jed/papers/Managing-Domains/#s6

If communicating objects (processes) can communicate and can thus 
communicate
permissions (at least by proxy), you may as well make it direct and easy 
for them
to do such communication of permissions.  They are collaborating to whatever
extent they wish in any case.

If we could get the computer security community (particularly the defense
community) to accept that position then I think we would be very far along
the road to having them accept capabilities and then to achieving POLA,
which I believe would significantly improve computer security throughout
our industry.

Unfortunately, they are disinclined to accept this position.  Trust programs
with manipulating permissions???  The horror!

I think another technical element that will help is to suggest a practice
of only providing capabilities that last for the duration of a computational
run to most programs.  That is, when I start up an application I give it
all revocable capabilities which I then revoke after the program completes.

Of course some few (e.g. file system managers and other trusted
"power" processes) need to be given what amount to permanent
capabilities to do their work (again POLA), but most programs can
get along with just temporary access.

I think this will help.  I really believe we need to turn this large 
community
around by getting them to see that they have little to lose and much to gain
by adopting the capability paradigm in order effectively approach POLA.
The fact that capabilities are nothing more than object oriented programming
with a bundling of access control seems to me another point that will make
this pill easier to swallow.

Naturally I'm quite interested to hear the opinion of others on this topic.
I don't expect many people from the relevant community to attend something
like the Horton discussion at HotSec, but maybe it can be a first shot
across the bow to get some attention?

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