<< Previous <<         [Session1 Index]            >> Next >>


Java security problems

E Security Enhancements

By the time you boil down Java's fundamental security failures, you find that all the failures can be remedied with only 3 new security-oriented constraints.

You have to prevent references to static members of  library classes that supply true capabilities, i.e., prevent references to static members that reach "outside" to fulfill a request. Objects with capabilities  are ok (as opposed to classes), because you can simply not give the  powerful object reference to the untrusted user. The problem with class methods (statics) is that, in Java, they are "global" in availability.

You have to prevent the creation of mutable static variables, i.e., static globally-accessible objects that can change state. Such variable easily break confinement: one object could change the value of the static variable, and another could read it, without ever properly passing a capability. To prevent such confinement-breaking requires more than just abolishing nonfinal static variables: if a final static variable is created, all the objects it contains must also be final, recursively, so that nothing changeable can be found.

Finally, because an untrusted class can, by the use of overloaded import shortcuts, pose as a trusted class, we need integrity checking on class references.

E solves these problems. E supplies a collection of client-side modules that augment the JVM, the E Vat. One part of the E Vat  is a set of secure E extensions that safely supply functionality that is unsafe in the JVM. Another part is the E Verifier.