[E-Lang] Re: Old Security Myths Continue to Mislead

[Jonathan S. Shapiro]

Okay. I tried to get Dan to do it, but as I failed...

Concening the "Complete Mediation" section of the "Stack Introspection"
paper:

Before being critical I wish first to say that in my opinion the Stack
Introspection paper is a brilliant piece of work. As I read it, the paper is
trying to solve the following problem: Given the existing Java object
library and runtime, and subject to the constraint that we are pragmatically
unable to rewrite all that code, what can be done to improve the security of
the system? Given this constraint, the method advanced in the paper is both
elegant and cost-effective. Further, it is unlikely that a successful
retrofit of capabilities into the existing Java object model would succeed.
There are both correctness and performance issues with doing so.

In critiquing a small and relatively tangential part of the paper, we must
not forget that this section is tangential, and that the essential value of
the paper remains unchanged. Whether pure capability mechanisms are a
technically correct solution for Java or not, their performance is
unacceptable. E works in part because it does not attempt to accept the Java
object system unmodified.

Fortunately, none of us are working on systems that are subject to this
constraint. The Mozart team, in particular, still has the opportunity to
design it's object system more intelligently than the Javasoft team (and no,
that's not intended to be an insult by way of setting a low hurdle :-.)

Okay. Time for my bottom line.

On the page http://www.cs.princeton.edu/sip/pub/sosp97/node13.html, *all* of
the assertions of the paragraph beginning "However,..." are simply wrong.
Further, no extensions to capabilities are required to get things right.
Given only the traditional, pure capability mechanisms, both complete
mediation and confinement are possible, and the claims about the need to
trust all of the software are therefore mistaken. Because mediation is
possible it is also incorrect that the number of trusted programs is
unbounded.


My objection to the "Complete Mediation" section of that paper is that it
makes broad, unsubstantiated claims about capability systems in general,
rather than their application in the particular context of Java. The subject
of the paper, however, is working around a set of problems with Java. Given
a completely buggered software design and implementation (Java), and a firm
requirement for compatibility, it should not be surprising that retrofitting
a new protection model doesn't work. Neither should it be argued that the
fault lies in the protection model.

The test of a scientific claim in a paper is whether it is substantiated.
This section offers neither quantitative nor qualitative reason to believe
the claims that are made. Even if these claims do apply to Java (which I
think they mostly do, but only for performance reasons), a satisfactory
presentation would present some argument for why these results should be
expected to generalize to other pointer- or capability-based systems.

Finally, I wish to point out in the paper's defense that while
counterexamples for the critical assertions of this section had been
published, they were published pretty obscurely. On the other hand, Boeberts
mistaken assertions about the failure of capability confinement, which
started the "capabilities cannot confine" misunderstanding, are clearly
wrong given only a cursory reading of the paper. On the other, a conclusive,
rigorous verification that capabilities can enforce confinement was not
published until 2000, which is three years after this paper. Please note
that the feasibility of confinement implies that complete mediation is
possible.

Bottom line:

This section of the paper makes broad claims that are both unsubstantiated
and incorrect in the general case. In the specific case of Java, given very
tight requirements, some of these objections to capabilities may apply **for
reasons of performance, not correctness**. It would be a mistake to draw any
general conclusion  about either the correctness or the performance of
capability systems from a single, ill-crafted example that was never
designed with capabilities in mind.


Jonathan