Java 2 Protection Domain and Permissions Model
A protection domain can be scoped by a set of objects that are currently directly accessible by a principal, where a principal is an entity in the computer system to which permissions are granted. A principal can access objects in the protection domain by virtue of the permissions it enjoys over the objects in the protection domain. These permissions are specified explicitly in a security policy file, which is a text file that can be edited manually or through the Policy Tool. The Java 2 security architecture allows the combination of a system security policy, defined by the system administrator, with one or more user-defined security policies. A default system policy file comes with the installation of the Java 2 SDK.
Notice that, even if an arbitrary number of policy files can be specified, there is only one policy (meaning, one set of protection domains) in effect for the JVM at any given time. That policy might be the result of processing the information from many policy files. The default policy implementation, via the java.security.Policy class, has a public refresh() method that can be used to re-init the policy, eventually re-reading the policy file(s). However, there is no automatic policy change: refresh() must be called explicitly.
Using this security model, it is possible to grant specific access permissions to specific code whether local or remote. Local or remote code is now identified by its code source. The code source for a code is a combination of the URL location from which the code is loaded and the entity or entities that signed the code originating from that location. The code source is represented by the java.security.CodeSource class. The location from which the code is loaded is passed as an argument to the constructor of the CodeSource class in the form of a java.net.URL object. The identity of the signer(s) is passed as the second argument to the constructor of the CodeSource object in the form of a set of java.security.cert.Certificate objects. These certificates are for the public keys corresponding to the private keys that signed the code. The constructor of the CodeSource class therefore looks like the following line:
public CodeSource(URL url, Certificate[] certs)
A policy file consists of a number of grant entries. The syntax of the grant entry is as follows:
Figure. The Syntax of a grant Entry in a Policy File
Notice that, even if the default policy implementation is file-based, application developers can implement their own Policy subclass, providing an implementation of the abstract methods in the java.security.Policy class. There could be multiple instances of the Policy class, even if only one is in effect at any time. The currently installed Policy object can be obtained by calling the static getPolicy() method in the Policy class. Codes with permission to reset the policy can change the currently installed Policy object by calling the static setPolicy() method in the Policy class.
A protection domain is identified as an association of a code source and the permissions granted to that code source. A code source is composed of a URL (code’s origination location) and optional signer(s). The permissions granted to a code source are specified in the policy file(s). When a non-system (non-trusted) class is loaded, it is mapped to a protection domain based upon its code source – where it was loaded from and any signers it may have. The grant entries in the policy file describe the permissions granted to a particular code source. Notice that classes that have the same permissions but are from different code sources belong to different protection domains.
Protection domains generally fall into two categories: system domain and application domains. We can think of the system domain as a single collection of all system code, which is not subjected to any policy restrictions and is granted all permissions. An application domain is specific to an application or applet and can include the domains of extensions as well, since even the standard extensions are subjected to the security policy specified in the policy file. The default java.policy file grants all extensions full access permissions to all system resources (java.security.AllPermission), provided the extension classes are stored as JAR files in the extensions directory ${java.home}\lib\ext or its subdirectories. On Windows systems, the default extensions directory is usually C:\Program Files\JavaSoft\JRE\1.2\lib\ext.
Notice that a thread of execution (which is often, but not necessarily, tied to a single Java thread, which in turn is not necessarily tied to the thread concept of the underlying operating system) may occur completely within a single protection domain or may involve an application domain and also the system domain. All protected resources, such as the file system, the networking facility, the screen and the keyboard, are accessible only via the system domains, as shown in the following figure:
Figure . Domain Composition of a Java Application Environment
Each class file loaded into the JVM via a class loader is assigned to one and only one protection domain, as determined by the code source of the class. However, multiple classes may be assigned to the same protection domain, depending on the code source itself. In addition, a single protection domain may include one or more permissions, and the same permission can be part of different protection domains.
The Java application environment maintains a mapping from code (classes and instances) to their protection domains and then to their permissions as shown in the following figure:
Figure . Mapping in the Java Application Environment
