[cap-talk] Language-based safety - notes and meat)
markm at cs.jhu.edu
Sun Nov 14 12:45:59 EST 2004
Jonathan S. Shapiro wrote:
> On Sun, 2004-11-14 at 11:49, Mark Miller wrote:
>>I waive that request. If E were implemented in C, E's security would not
>>depend on C's non-existent security. It had better not! For the current
>>E-on-Java implementation, Java is just an implementation language, like C
>>would be. E-on-Java's security depends no more on Java's security than an
>>E-on-C's implementation would depend on C's.
> Umm. Mark? You *do* know that the JVM can be beaten, don't you?
Which attacks or weaknesses do you have in mind?
Do you have some reason to believe that E would be vulnerable to those aspects
of the JVM you're worried about? We certainly tried to steer clear of
depending on aspects we were especially worried about. For example, we make no
use whatsoever of Java's so called security system (SecurityManager, stack
introspection, sandboxing, signed class files, etc...). Even if these were
completely broken, I don't think that would affect E at all.
The E implementation does assume that Java is memory safe. But even if another
memory unsafety bug was found -- for example, by a new flaw in the verifier --
even that worst case would only threaten E if one of the .class files that
come with Java, and that E code can cause to get loaded, can cause this bug to
Remember that, within our limited claims, the adversary does not get to add
new .class files to our system, just like they cannot add new .exe, .o, or .so
files to our system. (Or rather, that any files we get from the adversary will
not be treated by us as such files, unless the adversary exploits some other
flaw in E to get us to do so.)
> I'm not saying that E-on-Java is the wrong target. I'm saying that we
> should focus our attention on flaws in E rather than flaws in the JVM.
As far as focus of attention is concerned, I completely agree. However, I
don't want to place an attack at any level of abstraction out of bounds, so
long as the attack's point of entry is consistent with our limited claims
(.caplet and .emaker files loaded through the E loader).
> This is especially true if it is expected that the JVM is an interim
> solution rather than a long term commitment (I'm not clear whether the
> last is your intention).
The E language is the long term commitment. All implementations are interim.
The world is built on a succession of interim systems, or systems that should
be considered interim. Xerox PARC ran on the IFS, the "interim file system"
for even longer than we've been using E-on-Java. I'll tell the story sometime
of the origin of the x86 instruction set; but suffice it to say that few
instruction sets were created to be more interim than that one.
Whether interim or not, I intend the security of the current E-on-Java to be
taken seriously. If Jed does find a way to break E's security by exploiting a
JVM flaw, or a Windows/Linux flaw, or an x86 flaw, then he's done us a big
favor; and we'll try to figure out what to change about E so we're no longer
vulnerable to that flaw.
Text by me above is hereby placed in the public domain
More information about the cap-talk