What makes this goal particularly interesting is that, unlike UNIX, Java uses software-based protection (mostly based on type-safety) to achieve security. This leads to a very fine-grained system in which code with different trust levels (system code, code from different sources, etc.) is tightly interwoven.

Among other non-security-related topics that need to be addressed in a multi-user Java VM, we are especially interested in answering the following questions:

• How to combine user-based policies and code source based policies.

  Currently, Sun, Netscape etc. all provide for code source-based security policies, i.e. based on who signed an applet (or where it came from), certain actions are allowed or denied. However, in a multi-user VM, it also is important who is running the code. This should at least be an input into the decision-making process. One possible way to do this is to associate a principal with a thread or group of threads (an "application") and then combine the permissions of that principal with the permissions associated with the code itself (which are based on the code's origin). However, certain problems arise with this approach that might make it necessary to look for a better solution.

• Safe sharing between applications.

  A multi user, single address space, VM calls for sharing as an efficient means of communication across applications. However, for security reasons, every application should run in its own name space, prohibiting sharing by definition. Also, we know that sharing objects across name spaces (class loaders) may in some cases lead to breaches in the type system (at least in some Java implementations), which undermines all security mechanisms in a Java VM.

• Non-cooperative threads.

  In Java, there is currently no way to definitely stop a thread (a thread can catch the ThreadDeath exception that gets raised by the Thread.stop() method). This problem should also be of interest for other single address space operating systems: If we have threads that operate over the same address space, accessing the same objects (if not explicitly shared ones, then definitely through the shared system classes), it is not clear how to cleanly remove some of the threads without running the risk of leaving objects in an inconsistent state. In UNIX the unit of "killability" is a process, which usually doesn't share much with other processes. Sometimes they do (files, for example), and then we run into exactly the same problem: These files are left in an inconsistent state when one of the processes gets killed. In Java the unit of "killability" is a thread, and threads tend to share much more things. Hence, in Java this problem will be amplified.

Check out this paper for our first experiences with a multi-user Java VM.