[E-Lang] Announcing stl-E 0.8.9k: An interim non-distributed release

[Mark S. Miller]

At 02:57 PM Sunday 12/31/00, Jonathan S. Shapiro wrote:
>"Karp, Alan" wrote:
>> The goal is not to be perfect; it's to reduce the amount of code that has to
>> be examined by a person.  For example, executing any line of code that
>> accesses the file system will be caught by the security manager...
>
>Alan, I believe that you are neglecting the possibility of attacks
>perpetrated by bytecode written in Java assembler.
>
>You really need to take a look at the results that have come out of Ed
>Felton's group at Princeton. I believe you will conclude on reflection
>that the claim you are trying to assert is unsustainable.

I'm just re-joining this thread, so allow me to restate what I think the 
context is for Alan's remarks.  If I've got the context wrong, lemme know.

We're talking about figuring out how to subset or wrap the standard Java API 
as implemented by the standard Java libraries, in order to create a 
capability-safe and capability-oriented derived library, which is as 
familiar as reasonably possible for people who've learned the original 
API.  The specific case in front of us is Swing vs CapWT, but the 
techniques developed may then be applied to other APIs.

In all cases, we assume the prior API is part of our UTCB, and is not written 
to be purposely malicious.  However, we assume it was written without any 
cognizance whatsoever of capability security, other than that subset 
semi-enforced by Java itself.  As an example of "semi-enforce", let's take 
pointer safety.  Although Vijay Saraswat showed how Java code can subvert 
the type system and thereby compromise pointer safety 
http://www.cis.upenn.edu/~bcpierce/courses/629/papers/Saraswat-javabug.html
, it is unlikely for there to be any code that *unintentionally* engages 
in this attack.  So by "semi-enforce" I mean that it plausibly prevents all 
those who don't intend to do X from doing X.

With apologies to MarcS, think of a baby rather than a thief.  If handed a 
gun, a baby may in its innocent ignorance kill someone, but is unlikely to 
engage in complex subterfuges to hide the gun.  Ok, perhaps this is a bad 
example, but the principle is clear.  The existing standard Java APIs and 
libraries are capability-babies, not capability-attackers.  No one is 
proposing that we can figure out how to safely wrap locally untrusted (as in 
attacker) Java code with less effort than turning Java into a secure 
language.  For this among other reasons, the only locally untrusted code we 
support is E code.

So while the Princeton results, like Vijay's results, show Java's weakness 
at hosting locally untrusted code, I don't think either result is relevant 
to the issue of wrapping capability-baby APIs in order to create 
capability-safe and capability-oriented APIs.

Babies in the UTCB?

Of course, this raises the question of whether this baby vs attacker 
distinction is sufficiently sound for us to entrust with our life, liberty, 
and sacred honor.  I don't recall this ever having been explicitly 
discussed, and it certainly bears discussion.

I propose that the reasoning chain by which we come to believe that *any* 
UTCB is immune to, for example, the Ken Thompson attack is a reasoning chain 
that uses this baby vs attacker distinction.  For example, while Jonathan 
may be protecting himself in some ways from plausible accidental compiler 
bugs in compiling the EROS kernel, I see no way for him to protect himself 
(or us) from compilers that are out to get him.  The compiler cannot be 
assumed to have been written with the care of the EROS kernel, so we must 
assume it may be a baby, but we trust it not to be an attacker.  KeyKOS/360 
avoided depending on a compiler, but it did not avoid dependence on 
assemblers and hex dumpers and such.

Babies are still in our UTCB, but they weren't constructed to be in our 
UTCB. Any UTCB constructed using tools (including CPUs) that precede the 
conception of the UTCB cannot avoid including such babies in the UTCB.

Before further serious discussion of this topic, it would be great if 
someone would suggest better terminology. ;)



        Cheers,
        --MarkM