[cap-talk] Language-based safety - notes and meat)

[Mark Miller]

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 
be encountered.

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

     Cheers,
     --MarkM