<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jonathan S. Shapiro wrote:
<blockquote cite="mid1184173352.26134.44.camel@vmx.eros-os.org"
 type="cite">
  <pre wrap="">On Wed, 2007-07-11 at 17:22 +0100, David Hopwood wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
I strongly disagree and will go farther than Jonathan (below) in my
disagreement.<br>
<br>
The Trusted Computer Security Evaluation Criteria was the only credible
computer<br>
security evaluation criteria of the time.&nbsp; The community (DOD, etc.)
that were pushing<br>
these criteria were viewed at the time as having considerable market
clout and were<br>
taken very seriously.&nbsp; In a sense they were the only game in town.<br>
<br>
If instead of that document (I don't want to focus too much on that
particular<br>
document, but it was the highlight/lowlight and was very indicative)
they had<br>
written something to the effect:<br>
<br>
1.&nbsp; POLA is vital.&nbsp; We don't see how an effective market for software
can<br>
be developed that will be able to draw on multiple authoring sources
without<br>
a working mechanism for limiting the access of each author's software to<br>
just the authority it needs.<br>
<br>
2.&nbsp; We see some problems with capabilities - e.g. communicating
conspirators,<br>
MAC/MLS, and tracking/logging/auditing responsibility for actions, but<br>
these are problems that may be solved and we need to work on them and<br>
solve them in support of POLA,<br>
<br>
the history of computing from that time (1987) until today would have
been<br>
completely different.&nbsp; Unix would have adapted to POLA (instead as
various<br>
vendors did for it at the time to MAC and as in more recent times ACLs
as<br>
with SELinux) and Windows would have likely been very different and with<br>
POLA build in somehow.&nbsp; I really believe this.<br>
<blockquote cite="mid1184173352.26134.44.camel@vmx.eros-os.org"
 type="cite">
  <pre wrap="">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.

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
Hmmm.&nbsp; What would be the point of developing such an OS?&nbsp; We have had
many such<br>
operating systems in the past.&nbsp; Would running the PDP-1 supervisor, or
RATS, or NLTSS,<br>
or KeyKOS, or EROS, or ... on a PC with a full suite of applications
(at least in the<br>
case of NLTSS I can say so confidently) make any difference?&nbsp; Of course
not.&nbsp; Why<br>
would anybody do so?&nbsp; Who would fund such work?&nbsp; What would the point
be?<br>
<br>
It would only be if the IT community felt strongly that POLA and
capabilities were<br>
the right (only, effective, ...) solution to an important problem (e.g.
Trojan horses<br>
in their various forms) that such work would be seen as important,
would get<br>
funded and would be done.<br>
<br>
I argue that it is only by 'turning around' the IT (particularly the
computer security)<br>
community that we can get such work done with sufficient
force/influence to have<br>
an impact.<br>
<blockquote cite="mid1184173352.26134.44.camel@vmx.eros-os.org"
 type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
As I suggest, that report was just the poster boy for what was
happening in the<br>
community at the time that directly lead to the systems we have today.&nbsp;
This<br>
trend was of course set in motion with the original Multics and Unix and<br>
Tenex/TOPS/VMS systems of earlier days (Exec8, OS, WWMCCS,<br>
Burroughs/CANDE, and others basically followed), but the fact that the<br>
relevant computer security community of the time indicated, quite
clearly,<br>
that this existing 'user' based approach was the only approach that
could be<br>
considered secure (meet the Trusted Computer Security Evaluation
Criteria)<br>
and that POLA as represented by capabilities was fundamentally<br>
flawed was HUGELY influential.&nbsp; To argue otherwise is revisionist
history.<br>
<br>
This argument from that security community resulted in the systems we
have<br>
today.&nbsp; To change this situation and to create a market where we can
confidently<br>
mix software from a variety of sources in our applications we need to at<br>
least refute the arguments made and still believed by this community.&nbsp;
We<br>
also need to create consensus that POLA is needed (and positive - vs.<br>
being considered a detriment and negative - e.g. consider the widely<br>
accepted comments by Butler Lampson) before we can get on to solving<br>
the technical problems and effectively dealing with a transition to a
more<br>
effective computing environment.<br>
<br>
<br>
One thing I should mention about the above discussion.&nbsp; I've been using<br>
POLA and capabilities somewhat interchangeably.&nbsp; Of course I recognize<br>
that POLA is a principle that can be achieved by a variety of
technologies.<br>
In principle one can even achieve POLA with 'user' based access control<br>
and ACLs - e.g. by having every process or object run as a separate<br>
'user' and assigning permissions appropriately.&nbsp; The trouble of course
is<br>
that any such 'user' /ACL approaches to POLA have proven (and I argue<br>
inevitably will prove) horribly awkward and completely impractical.<br>
<br>
Object/capabilities are very simply object/parameter computing.<br>
This technology goes back to the first parameters to subroutines<br>
in the beginning of computing.&nbsp; It's been refined over the years until<br>
we have the OO computing that we have today, but outside the<br>
language area access control schemes have, I believe, been overly<br>
influenced my human views of human institutions.&nbsp; Of course we want<br>
our computers to do our bidding.&nbsp; We need to bend them to our will,<br>
not in any sense the other way around.&nbsp; However, I argue that this<br>
simple passing of "object" parameters to all active entities is in fact<br>
the best way to get them to safely do our bidding.&nbsp; That as we see in<br>
mechanisms like Horton, we can include personal human responsibility<br>
in such systems in very natural ways by simply labeling the object<br>
reverences as to who is responsible for actions on them.<br>
<br>
--Jed&nbsp; <a class="moz-txt-link-freetext" href="http://www.webstart.com/jed/">http://www.webstart.com/jed/</a><br>
</body>
</html>