[E-Lang] Announcing stl-E 0.8.9k: An interim
Mark S. Miller
Sun, 31 Dec 2000 23:05:36 -0800
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
, 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. ;)