Protection Domains

As class loaders load types into the Java virtual machine, they assign each type into a protection domain. A protection domain defines all the permissions that are granted to a particular code source. (A protection domain corresponds to one or more grant clauses in a policy file.) Each type loaded into a Java virtual machine belongs to one and only one protection domain.

The class loader knows the codebase and the signers of any class or interface it loads. It uses that information to create a CodeSource object. It passes the CodeSource object to the getPermissions() method of the currently in-force Policy object to get an instance of a subclass of the abstract class java.security.PermissionCollection. The PermissionCollection holds references to all Permission objects granted to the given code source by the current policy. With both the CodeSource that it created and the PermissionCollection it got from the Policy object, it can instantiate a new ProtectionDomain object. It places the code into a protection domain by passing the appropriate ProtectionDomain object to the defineClass() method, an instance method of class ClassLoader that user-defined class loaders call to import type data into the Java virtual machine. This assigning classes into protection domains is a critical job which, as mentioned earlier in this chapter, is one of three ways the class loader architecture supports Java's sandbox security model.

Although the Policy object represents a global mapping from code sources to permissions, in the end the class loader is the responsible party that decides what permissions code is going to get when it runs. A class loader could, for example, completely ignore the current policy and just assign permissions off the cuff. Or, a class loader could add permissions to those returned by the policy object's getPermissions() method. For example, a class loader for loading applet code could add a permission to make a socket connection back to the host from which the applet came to the permissions, if any, granted to the code by the policy. As you can see, the class loader plays a crucial security role as it loads classes.

For a graphical depiction of protection domains, code sources, and permissions, consider Figure 3-5. In Figure 3-5, the method area and heap are shown after the code inside friend.jar is loaded under the policy defined by policyfile.txt. friend.jar is a JAR file in the security/ex2/jars directory of the CD-ROM, and policyfile.txt is an ASCII policy file in the security/ex2 directory. The friend.jar file contains two class files, Friend.class and Friend$1.class. As described in the code signing example earlier in this chapter, both of these class files have been signed by friend. When these classes are defined by the class loader, they are placed into a protection domain whose CodeSource object indicates two things. First, the CodeSource indicates that the class files were loaded from a local jar file, whose URL is: file:///f|/security/ex2/jars/friend.jar. And second, the CodeSource indicates that the class files were signed by friend, an alias associated with a certificate in the local keystore. The ProtectionDomain object encapsulates a reference to the CodeSource object and to a java.security.Permissions object. java.security.Permissions, a concrete subclass of the abstract java.security.PermissionCollection class, represents a heterogeneous collection of permissions. The Permissions object holds references to two java.io.FilePermission objects. These two FilePermissions grant the privilege to read files named question.txt and answer.txt in the current directory.

When a class loader imported Friend and Friend$1 into the method area shown in Figure 3-5, the class loader passed a reference to the ProtectionDomain object to defineClass() along with the bytes of the class files. The defineClass() method associated the type data in the method area for Friend and Friend$1 with the passed ProtectionDomain object. This association is shown graphically in Figure 3-5, which includes arrows that represent references to the ProtectionDomain object held as part of the type data in the method area for Friend and Friend$1.

Figure 3-5. Protection domains, code sources, and permissions.