Strong Encryption

To ensure the privacy of data on the network, communication channels are encrypted with symmetric-key ciphers. We assume symmetric key encryption is powerful enough that attackers cannot decrypt data before it loses its value. We also assume that public key encryption, private key signatures, and message authentication codes are strong.

Compromise of channel encryption can allow eavesdroppers to read private data from the network. Compromise of digital signatures or message authentication codes can allow attackers to undetectably alter private data, thus destroying the integrity of the data. TEP depends on these cryptographic mechanisms to provide privacy and integrity guarantees.

4.1.2 Process Isolation

Each program that runs on TEP resides in its own logicalprocess: each process has its own memory, class namespace, and access to system resources. Since TEP is a shared

service, it must provide process isolation to ensure that no process can interfere with the memory or namespace of other processes. This is vital for protecting the privacy of data used in computation.

Since all processes run on the same physical machine, TEP must implement pro-cess isolation within its trusted computing base. TEP runs each propro-cess in a thread on TEP’s own Java Virtual Machine. By running processes as threads, rather than as separate virtual machines, TEP improves performance, reduces system load, and simplifies process management. Since threads can use shared variables to communi-cate values and create covert channels, TEP must ensure that its application threads cannot share data.

The work described in this thesis does not fully implement the process model.

Instead, we use Java language constructs, custom Java classloaders, and the Java se-curity manager to provide memory isolation and to control access to system resources.

The following sections describe these mechanisms and define how Jif programs access TEP’s resources. More advanced systems for isolating processes in Java are described in Chapter 6.

Class Isolation

To separate the class namespaces of different applications, we have implemented a custom Java classloader for TEP applications. Since different applications can have classes with the same name, TEP must ensure that separate applications cannot load each other’s classes. Otherwise, an application may attempt to load a class that does not link correctly with its own classes.

Each application that runs on TEP has its own private classloader, known as the application classloader. Each Java classloader provides a separate class namespace and static class data [LB98]. This ensures that separate applications running on TEP cannot access each other’s classes or static data. Jif does not allow classes to have static variables, so the only static data in a class is the class object itself.

Multiple instances of the same application can run on TEP at the same time and can share a common application classloader. Since Jif classes cannot have static variables, these instances do not share any common class variables. However, these instances can communicate by synchronizing on the class object using class methods.

To prevent this, Jif does not allow the use of the synchronized keyword.

Each application classloader loads code only from a single JAR file, so each client program must be packaged in a single JAR file. Since classes are stored as separate entries in the JAR file and Java requires that classes have the same name as their file, each application can have at most one class with a given name. This ensures that there is no ambiguity about which class to load for a given name.

Each application classloader defers to the system classloader and TEP’s own class-loader before loading classes from its JAR file, so foreign classes cannot override Java system classes or TEP’s own classes. The application classloader also rejects any classes in the JAR that declare package tep: this prevents foreign classes from ac-cessing TEP’s package-private data.

Memory Isolation

Memory isolation ensures that one process cannot read from or write to the memory of another process. Although Jif labels protect the privacy of data in these programs, labels do not stop programs from using shared data to communicate. To prevent this, TEP does not allow separate application threads to share mutable variables. Threads may share read-only variables, such as an application classloader or system classes, but mutable variables are stored on each thread’s local stack or in heap variables referenced from the thread’s stack. If applications need to exchange data, they must do so through channels or persistent objects. The API for these functions is given later in this section.

All of TEP’s implementation resides in classes in package tep, so client programs can only access TEP’s public classes and methods. These methods and classes provide various services to the applications, but they do not reveal TEP’s private data or data from other applications.

Controlling System Resources

Access to TEP’s file system and the network is controlled using the Java security manager. Since the file system contains TEP’s private data and implementation, foreign code must not be allowed to read or write files. Since the network is untrusted and open to eavesdroppers, all communications must be controlled by TEP to ensure privacy.

The Java security manager works by enforcing policies for various sets of classes.

Each policy grants a set of permissions for accessing system resources to a particular set of classes. Java system classes are implicitly given all permissions, since they control access to the system directly [Jav98]. Jif programs running on TEP do not have direct access to the Java system classes; instead, we provide Jif versions of the standard library classes. These classes allow Jif programmers to use the standard Java APIs while providing appropriate information flow labels.

TEP’s security manager grants TEP’s own classes permission to access all re-sources but denies permission to all other classes.¹ If a foreign class attempts to access a restricted method or class, a runtime AccessControlException is thrown.

It would be more efficient to make these checks statically; this is left for future work.

When foreign classes need to access the network, they must use TEP’s privileged TepChannel class. This class ensures that private data written to the channel is protected from unauthorized principals (Section 4.3.5). Similarly, persistent objects must be stored using TEP’s privileged TepSealedObject class. This class protects classified data when stored on untrusted servers (Section 4.3.6).

1Following the principle of least privilege, TEP should be granted only the permissions it requires.

Determining this set of permissions is left for future work.

Controlling Thread Creation

Since Jif is a single-threaded language, TEP must prevent its applications from cre-ating threads. Unfortunately, the Java security manager does not provide a way to control thread creation. Ideally, the start() method in class java.lang.Thread should throw a runtime exception if called from foreign code.²

Since this mechanism is not available, we assume that the static analysis per-formed by the Jif Checker rejects classes that attempt to create threads. We feel this assumption is reasonable and, in fact, provides a more efficient mechanism than runtime checks.