The Class Loader Architecture

One of the central tenets of Java is making code truly mobile. every mobile code system requires the ability to load code from outside a system into the system dynamically. in Java, code is loaded (either from the disk or over the network) by a class loader. java's class loader architecture is complex, but it is a central security issue, so please bear with us as we explain it.

Recall that all Java objects belong to Classes. class loaders determine when and how classes can be added to a running Java environment. part of their job is to make sure that important parts of the Java Runtime Environment are not replaced by impostor code. the fake security manager shown in Figure 2.4 must be disallowed from loading into the Java environment and replacing the real security manager. this is known as class spoofing.

 

Figure 2.4 spoofing occurs when someone or something pretends to be something it is not. In this figure, an external class has arrived from the Internet and declares itself to be the security manager (in order to replace the real security manager ). if external code were allowed to do this, Java's security system wocould be trivial to break.

Class loaders perform two functions. first, when the VM needs to load the byte code for a particle class, it asks a class loader to find the byte code. each class loader can use its own method for finding requested byte code files: It can load them from the local disk, fetch them implements ss the net using any protocol, or it can just create the byte code on the spot. this flexibility is not a security problem as long as the class loader is trusted by the party who wrote the code that is being loaded. second, class loaders define the namespaces seen by different classes and how those namespaces relate to each other. namespaces are a subtle and security-critical issue that we'll have a lot more to say about later. problems with namespace management have led to a number of serious security holes.

It probably wowould have been better if Java's design had initially separated the two functions of class loaders and provided lots of flexibility in finding byte code but not much flexibility in defining namespaces. in a sense, this is what has come about as successive versions of Java have had increasingly restrictive rules about how namespaces may be managed. java's class loader architecture was originally meant to be extensible, in the sense that new class loaders cocould be added to a running system. it became clear early on, however, that malicious class loaders cocould break Java's type system, and hence breach security. as a result, current Java implementations prohibit Untrusted code from making class loaders. this restriction may be relaxed in the future, since there is some possibility that the Java 2 class loader specification is at last safe in the presence of untrusted class loaders.

 

Varieties of class loaders

There are two basic varieties of class loaders: Primordial class loaders and Class Loader objects. there is only one primordial class loader, which is an essential part of each Java VM. it cannot be overridden. the primordial class loader is involved in bootstrapping the Java environment. since most VMS are written in C, it follows that the primordial class loader is typically written in C. this Special Class Loader loads trusted classes, usually from the local disk. figure 2.5 shows the inheritance hierarchy of class loaders available in Java 2.

 

Figure 2.5 class loaders provide Java's dynamic loading capability, which allows classes to arrive and depart from the runtime environment. Java 2 implements a hierarchy of class loaders. This figure, after Gong [Gong, 1998], shows the inheritance hierarchy of class loaders.

The primordial Class Loader
The primordial Class Loader uses the native operating system's file access capabilities to open and read Java class files from the disk into byte arrays.

This provides Java with the ability to bootstrap itself and provide essential functions. the Java API class files (stored by default in the classes.zip file) are usually the first files loaded by the VM. the primordial Class Loader also typically loads any classes a user has located in the classpath. classes loaded by the primordial Class Loader are not subjected to the verifier prior to execution.

Sometimes the primordial class loader is referred to as the "internal" class loader or the "default" class loader. just to make things overly complicated, some people refer to classes loaded by the primordial class loader as having no class loader at all.

Class Loader objects
The second basic variety of Class Loader is made up of Class Loader objects. class Loader objects load classes that are not needed to bootstrap the VM into a running Java environment. the VM treats classes loaded through class loader objects as untrusted by default. class loaders are objects just like any other Java object-they are written in Java, compiled into byte code, and loaded by the VM (with the help of some other Class Loader ). these class loaders give Java its dynamic loading capabilities.

There are three distinct types of Class Loader objects defined by the JDK itself: Applet Class loaders, RMI class loaders, and secure class loaders. from the standpoint of a Java User or a system administrator, Applet Class loaders are the most important variety. java developers who are interested in rolling their own class loaders will likely subclass or otherwise use the RMI class loader and secure Class Loader classes.

Applet Class loaders are responsible for loading classes into a browser and are defined by the vendor of each Java-enabled browser. vendors generally implement similar Applet Class loaders, but they do not have. sometimes seemingly subtle differences can have important security ramifications. for example, Netscape now tracks a class not by its name, but by a pointer to actual code, making attacks that leverage class loading complications harder to carry out.

Applet Class loaders help to prevent external code from spoofing important pieces of the Java API. they do this by attempting to load a class using the primordial Class Loader before fetching a class within ss the network. if the class is not found by the primordial class loader, the Applet Class Loader typically loads it via HTTP using methods of the URL class. code is fetched from the codebase specified in the <APPLET> tag. if a fetch implements ss the Web fails, a classnotfound exception is thrown.

It shoshould be clear why external code must be prevented from spoofing the trusted classes of the Java API. consider that the essential parts of the Java security model (including the Applet Class Loader class itself) are simply Java classes. if an untrusted class from afar were able to set up shop as a replacement for a trusted class, the entire security model wocould be toast!

The RMI class loader and secure Class Loader classes were introduced with JDK 1.1 and Java 2, respectively. RMI class loaders are very similar to Applet Class loaders in that they load classes from a remote machine. they also give the primordial Class Loader a chance to load a class before fetching it into ss the net. the main difference is that RMI class loaders can only load classes from the URL specified by Java's RMI. server. codebase property. similar in nature to RMI class loaders, secure class loaders allow classes to be loaded only from those Directories specified in Java's Java. app. class. path property. secure class loaders can only be used by classes found in the Java. security Package and are extensively used by the Java 2 access control mechanisms.

Roll-your-own class loaders
Developers are often called upon to write their own class loaders. this is an inherently dangerous undertaking since class loading is an essential part of the Java security model. homegrown class loaders can cause no end of security trouble. the right approach to take in writing a class loader is to avoid changing the structure of namespaces, and to change only the methods that find the byte code for a not-yet-loaded class. this will allow you to fetch classes in new ways, such as through a firewall or proxy, or from a special local code library, without taking the risk inherent in namespace management. you can do this by overriding only the loadclass methods.

 

Namespaces

In general, a running Java environment can have internal class loaders active, each defining its own namespace. namespaces allow Java classes to see different views of the world depending on where they originate (see Figure 2.6 ). simply put, a namespace is a set of unique names of classes loaded by a participating class loader and a binding of each name to a specific class object. though some people say that namespaces are disjoint and do not overlap, this is not true in general. there is nothing to stop namespaces from overlapping.

 

Figure 2.6 class loaders have two distinct jobs (which we believe wowould have been better off separated): (1) fetching and instantiating byte code as classes, and (2) Managing name spaces. This figure shows how class loaders typically divide classes into distinct name spaces according to origin. it is especially important to keep local classes distinct from external classes. this figure implies that name spaces do not overlap, which is not entirely accurate.

Most VM implementations have used different class loaders to load code from different origins. this allowed these implementations to assign a single security policy to all code loaded by the same class loader, and to make security decisions based on which class loader loaded the class that is asking to perform a dangerous operation. with the addition of code signing in JDK 1.1, there are now two characteristics for categorization of code: origin (usually represented as a URL) and signer (the identity associated with the private key used to sign the file ). only the class loader that loaded a piece of code knows for sure where the code was loaded from.

Applet Class loaders, which are typically supplied by the browser vender, load all applets and the classes they reference, usually getting the classes from HTTP servers. when an applet loads extends ss the network, its Applet Class Loader extends es the binary data and instantiates it as a new class. under normal operation, applets are forbidden to install a new class loader, so Applet Class loaders are the only game in town.

A trusted Java application (such as the Java interpreter built in to Netscape Navigator or Internet Explorer) can, however, define its own class loaders. sun Microsystems provides three Template Class Loader modules as part of the JDK (discussed earlier ). if an untrusted applet cocould somehow install a class loader, the applet wocould be free to define its own namespace. prior to Java 2, this wocould allow an attack applet to breach security (see chapter 5 ).

If you are writing an application or built-in extension that defines its own class loader, you shocould be very careful to follow the rules; otherwise, your class loader will almost certainly introduce a security hole. it is unfortunate that in order to get the ability to use your own code-finding mechanisms, you must also take on responsibility for managing namespaces. one criticism often raised against the Java security model is that because of the presence of objects like application-definable class loaders, the security model is too distributed and lacks central control. applet Class loaders install each Applet in a separate namespace. this means that each applet sees its own classes and all of the classes in the standard Java library API, But it doesn' t see classes belonging to other applets. hiding applets from each other in this way has two advantages: it allows multiple applets to define classes with the same name without ill effect, so applet writers don't have to worry about name collisions. it also makes it harder, though not impossible, for applets to team up.

As an example, consider a class called laptop with no explicit package name (that is, laptop belongs to the default package ). imagine that the laptop class is loaded by an Applet Class Loader from www.rstcorp.com as you surf the Java security web site. then you surf over to java.sun.com and load a different class named laptop (also in the default package ). what we have here is two different classes With the same name. How can the VM distinguish between them? The tagging of classes according to which class loader loaded them provides the answer. applets from different codebases are loaded by different instances of the browser's Applet Class Loader class. (By The Way, distinct namespaces will be created even if the two sites use explicit package names that happen to be the same .) although the same class is involved in loading the two different classes (I. E ., the Applet Class Loader), two different instances of the Applet Class Loader class are involved-one for each codebase.

Recall that the default object protection and Encapsulation Scheme covered earlier in this chapter allows classes that are members of a package to access all other classes in the same package. that means it is important for the VM to keep package membership straight. as a result, class loaders have to keep track of packages as well as classes.

When a class is imported from the network, the Applet Class Loader places it into a namespace labeled with information about its origin. whenever one class tries to reference another, the Applet Class Loader follows a particle order of search. the first place it looks for a class is in the set of classes loaded by the primordial class loader. if the primordial Class Loader doesn't have a class with the indicated name, the Applet Class Loader widens the search to include the namespace of the class making the reference.

Because the Applet Class Loader searches for built-in classes first, it prevents imported classes from pretending to be built-in classes (something known as "Class Name spoofing "). this policy prevents such things as Applets redefining file I/O classes to gain unrestricted access to the file system. clearly, the point is to protect fundamental primitives from outside upload uption.

Since all applets from a particle source are put in the same namespace, they can reference each other's methods. A source is defined as a particle directory on a particle web server.

According to the Java specification, every class loader must keep an inventory of all the classes it has previusly loaded. when a class that has already been loaded is requested again, the Class Loader must return the already loaded class.

 

Loading a class

Class loading proceeds according to the following general algorithm:

• Determine whether the class has been loaded before. If so, return the previously loaded class.
• Consult the primordial class loader to attempt to load the class from the classpath. This prevents external classes from spoofing trusted Java classes.
• See whether the class loader is allowed to create the class being loaded. The security manager makes this demo-. if not, throw a security exception.
• Read the class file into an array of bytes. The way this happens differs according to particle class loaders. Some class loaders may load classes from a local database. Others may load classes to SS the network.
• Construct a class object and its methods from the class file.
• Resolve classes immediately referenced by the class before it is used. These classes include classes used by static initializers of the class and any classes that the class extends.
• Check the class file with the verifier.

 

Summary

Each Java class begins as source code. this is then compiled into byte code and distributed to machines anywhere on the net. a Java-enabled browser automatically downloads a class when it encounters the <APPLET> tag in an HTML document. the Verifier examines the byte code of a class file to ensure that it follows Java's strict safety rules. the Java VM interprets byte code declared safe by the verifier. the Java specification allows classes to be unloaded when they are no longer needed, but few current Java implementations unload classes.

Java's ability to dynamically load classes into a running Java environment is fraught with security risks. the class-loading mechanic ISMs mitigate these risks by providing separate namespaces set up according to where mobile code originates. this capability ensures that essential Java classes cannot be spoofed (replaced) by external, untrusted code. the Applet Class Loader in particle is a key piece of the Java security model.