Nested Java Processes: OS Structure for Mobile Code

Summary. The authors argue that language-based mechanisms alone cannot provide sufficient safety for mobile code environments because they do not manage resources. Rather, to adequately manage resources, an OS model is required. The insight is that "protection, separation, and control of resources used by mutually untrusting components, applets...are exactly the same problems faced by multi-user operating systems" so, why not just use the OS model?

The authors have implemented the Fluke microkernel model inside of a Java VM.

More Detail...

• Existing security approaches tend to be ad hoc and fall short.
• A "full-blown" OS model should be used.
• Such an approach is feasible.
• Such an approach offers novel features:
  • Hierarchical resource management.
  • More flexible object sharing.

Motivational AN application. MCI's DenialOfService Tracker needs access to routers, and more-specifically, requires that routers implement a special interface. Although MCI was able to build their network using interface compliant routers, they do not have control over routers outside their administrative domain which may or may not have the required interface.

The above problem is solved if routers were able to run small programs on their routers i.e., if we had active networks. However, one could do this with mobile code; the "aggressive" AN vision of "code in any packet" is not necessary for this and many examples.

A second example: MCI routers currently allocate CPU time to their customers in a hierarchical manner. The Fluke model's hierarchical extensible resource management model would be useful.

Resource management required. The authors state that mobile code that implements apps such as the DosTracker, resource mgt is necessary. This is a little vague -- but I assume their argument is that, since the code runs with no human user to watch that it doesn't get out of control (as a user does with applets running in a browser) things could get out of hand easily. They say resource mgt should be done using the process abstraction of old. State that Java environment is not adequate - "little more than threads with a few ad hoc constraints."

Current approaches "inadequate": (This section is a little harsh, but Pat says that's the tone of the conference.)

• JDK1.2. Has ACLs and signed code. ACLs: error prone at large scale. No notion of user authentication. Lots of other bad points mentioned but not explained.
• Other Java security approaches. Capabilities, stack introspection, name space mgt. "These are only mechanisms for controlling code", not comprehensive designs.
• JavaOS. Appears to be a single JVM with no protection between applets.
• Oberon. Single-threaded, non-preemptive OS that uses type-safety for protection. Global state available, so global resources available with no way of reclaiming them.
• J-Kernel.Impose a capability system on JVM. No resource management (CPU accounting).
• Dedicated host. Java Playground, Cage. Applets run on dedicated, isolated hosts. Restricts model to Java applet model (overly restrictive).
• Lava. Provides good security between JVMs with "acceptable" cost. No resource mgt.
• Others. Eclipse. Joust+Escort. Nemesis.

Proposed Solution: Use OS Model inside a JVM. Use the Fluke microkernel model. Fluke advantages:

• Nested-process model. Optionally expose all resources required by child to the parent.
• Inheritance scheduling. Allows user threads to schedule children.

Two goals:

1. Determine extend to which a Java-based system can provide traditional OS environment.
2. Bring the nested process model to Java.

Assorted good points made:

• Fluke design assumed hw protection, but abstractions don't.
• In Java, can leverage type-safety to improve NPM. Ex: in Fluke, objects have a user portion and system portion; system portion must be fetched by kernel. In Java: easily implemented w/private and protected keywords.
• Authors contend that JVM modification can be restricted to a few key classes.
• Because mobile code is likely to be in a type-safe language, adding the OS structure into a safe-language environment can reduce overhead of managing/communicating between two systems. Ex: Lava has to instantiate a JVM and communicate via Java RMI in order to run Java code.
• Resource accounting is tricky in presence of GC -- tasks' allocations affect each other.