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

E

Java security problems

• No reference to capability-supplying static members
• No nonfinal static variables, no mutable final statics
• Integrity checking of class references

E Security Enhancements

• E Vat
• Secured Functionality Available via E Vat
• E Verifier

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.