<< Previous << [Session1 Index] >> Next >>
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.