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

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Wed, 2007-07-11 at 17:22 +0100, David Hopwood wrote:
>   
>>> I chose to focus particular attention on this document:
>>>
>>> Traditional Capability-Based Systems: An Analysis of
>>> Their Ability to Meet the Trusted Computer Security
>>> Evaluation Criteria
>>>       
>> I have to say that I think you are drastically overestimating the
>> effect that papers such as this one had on the history of adoption
>> of security mechanisms.
>>     
>
>   
I strongly disagree and will go farther than Jonathan (below) in my 
disagreement.

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 (I don't want to focus too much on that 
particular
document, but it was the highlight/lowlight and was very indicative) 
they had
written something to the effect:

1.  POLA is vital.  We don't see how an effective market for software can
be developed that will be able to draw on multiple authoring sources without
a working mechanism for limiting the access of each author's software to
just the authority it needs.

2.  We see some problems with capabilities - e.g. communicating 
conspirators,
MAC/MLS, and tracking/logging/auditing responsibility for actions, but
these are problems that may be solved and we need to work on them and
solve them in support of POLA,

the history of computing from that time (1987) until today would have been
completely different.  Unix would have adapted to POLA (instead as various
vendors did for it at the time to MAC and as in more recent times ACLs as
with SELinux) and Windows would have likely been very different and with
POLA build in somehow.  I really believe this.
> While I agree in general, in this particular case the paper was
> influential. First, it was widely circulated and known among the US
> authors of the Common Criteria and the Federal Criteria. It was also
> well known among the people at NSA who were viewed as thought leaders on
> secure systems. I've had it cited to me as a conclusive report by senior
> technical people who really ought to know better.
>
> Second, IDA's main purpose is to identify forward-looking research
> directions for US Federal research funding. If IDA came out with a
> credible report stating that a given direction wasn't interesting (and
> this one, given the authors, was certainly considered credible), you may
> safely assume that the report had a negative influence on research
> funding. This in turn had a negative impact on investigation and
> teaching of this technology area, which in turn had a significant role
> in marginalizing the ideas in the eyes of mainstream academic computer
> scientists and their students.
>
>   
>> We cannot blame anyone outside the capabilities community for our
>> collective failure to produce a capability OS that is complete enough
>> to run even a few basic demonstration apps on a PC.
>>     
>
>   
Hmmm.  What would be the point of developing such an OS?  We have had 
many such
operating systems in the past.  Would running the PDP-1 supervisor, or 
RATS, or NLTSS,
or KeyKOS, or EROS, or ... on a PC with a full suite of applications (at 
least in the
case of NLTSS I can say so confidently) make any difference?  Of course 
not.  Why
would anybody do so?  Who would fund such work?  What would the point be?

It would only be if the IT community felt strongly that POLA and 
capabilities were
the right (only, effective, ...) solution to an important problem (e.g. 
Trojan horses
in their various forms) that such work would be seen as important, would get
funded and would be done.

I argue that it is only by 'turning around' the IT (particularly the 
computer security)
community that we can get such work done with sufficient force/influence 
to have
an impact.
> I agree. Also, we shouldn't spend time trying to rebut the report. The
> right way to do that is with a followup report from IDA, and I think I
> may know where to plant that idea.
>
> But to the extent that this report framed an environment in which
> capability research was disregarded as irrelevant, and to the extent
> that research funding is important to the long-term success of these
> ideas, this particular report is well worth knowing about.
>   
As I suggest, that report was just the poster boy for what was happening 
in the
community at the time that directly lead to the systems we have today.  This
trend was of course set in motion with the original Multics and Unix and
Tenex/TOPS/VMS systems of earlier days (Exec8, OS, WWMCCS,
Burroughs/CANDE, and others basically followed), but the fact that the
relevant computer security community of the time indicated, quite clearly,
that this existing 'user' based approach was the only approach that could be
considered secure (meet the Trusted Computer Security Evaluation Criteria)
and that POLA as represented by capabilities was fundamentally
flawed was HUGELY influential.  To argue otherwise is revisionist history.

This argument from that security community resulted in the systems we have
today.  To change this situation and to create a market where we can 
confidently
mix software from a variety of sources in our applications we need to at
least refute the arguments made and still believed by this community.  We
also need to create consensus that POLA is needed (and positive - vs.
being considered a detriment and negative - e.g. consider the widely
accepted comments by Butler Lampson) before we can get on to solving
the technical problems and effectively dealing with a transition to a more
effective computing environment.


One thing I should mention about the above discussion.  I've been using
POLA and capabilities somewhat interchangeably.  Of course I recognize
that POLA is a principle that can be achieved by a variety of technologies.
In principle one can even achieve POLA with 'user' based access control
and ACLs - e.g. by having every process or object run as a separate
'user' and assigning permissions appropriately.  The trouble of course is
that any such 'user' /ACL approaches to POLA have proven (and I argue
inevitably will prove) horribly awkward and completely impractical.

Object/capabilities are very simply object/parameter computing.
This technology goes back to the first parameters to subroutines
in the beginning of computing.  It's been refined over the years until
we have the OO computing that we have today, but outside the
language area access control schemes have, I believe, been overly
influenced my human views of human institutions.  Of course we want
our computers to do our bidding.  We need to bend them to our will,
not in any sense the other way around.  However, I argue that this
simple passing of "object" parameters to all active entities is in fact
the best way to get them to safely do our bidding.  That as we see in
mechanisms like Horton, we can include personal human responsibility
in such systems in very natural ways by simply labeling the object
reverences as to who is responsible for actions on them.

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