At this time, Lilith security is in the design and prototype stage, and is designed to work with the Lilly classes. The goal of the current security architecture is to provide a proof of concept under which a machine owner can ensure that users running a LillyLilim on his host are subject to constraints that he defines. These constraints can vary on a per-user basis. The ultimate goal of the security architecture is to provide flexible security on a per-user, per-invocation basis. This security will also include mechanisms for authentication (veryifying the users identity) and message integrity.

We presuppose a state in which the LilithHost owner has the user's public key in his .keystore file. When the user wants to run a LillyLilim on a remote host, he sends his identity over with the LillyLilim. The LilithHost running on that node provides a unique class loader for each user that associates all classes loaded through the loader with a Code Source associated with the user's key. The LilithHost loads a user's LillyLilim and all classes subsequently required by the LillyLilim through the user specific class loader. In this way, instances of a class are associated with a particular user. The multiple class loader configuration is necessary as Java is inherently class-centric and provides no straightforward route to associate a particular instance of a class with a user.

Constraints are placed upon a user's class by allowing or disallowing it Permissions. The set of possible Permissions consists of Java defined Permissions, Lilith defined Permissions, and any other special case Permissions the LilithHost owner (or other) chooses to define. Java defined Permissions include, for example, network and file access. Lilith defined Permissions are those associated with the calls buildtree, sendlilim, and runlilim. An example of special case Permissions would be those that the LilithHost owner might define for his own classes he allows the user to access. The LilithHost owner grants users' classes specific Permissions in the .java.policy file. Whenever calls associated with a Permission are invoked, Java performs a security check. Java allows a call to take place if all classes in the execution stack have the required Permissions (or if a class in the stack has such permission and is specifically written to take the responsibility of invoking a call on behalf of other classes higher up in the stack.) Thus, the .java.policy file and Lilith's user-specific class loader scenario together link users, classes, and Permissions.

The LilithHost owner's .java.policy file should give Lilith classes This allows the Lilith classes to make, for example, network and file accesses where necessary. The LilithHost owner can apply specific contraints on specific users' classes by allowing or disallowing individual Permissions on a per-user basis.

The design of the Lilith-LillyLilim interactions makes it especially easy to permit Lilith necessary accesses, deny specific users specific accesses, and be assured that the users' classes can not abuse the greater Lilith accesss for their benefit.

Future Work

scalability - accessing a single .java.policy file and .keystore is a bottleneck