Elements of the Java Sandbox

Code sources Code sources are the location from which a class has been loaded along with information about who signed the class, if applicable. The location is specified as a URL, which follows standard Java practice: code can be loaded from the file system through a file−based URL or from the network via a network−based URL. If code is signed, information about the signer is included in the code source. However, its important to note that the URL and signer information in a code source are both optional. Classes can be assigned permissions based only on the URL from which the class was loaded, based only upon who signed the class, or a combination of both. Hence, it is not required that code be signed in order for it to carry special permissions. The URL within a code source is called a codebase. Protection domains A protection domain is an association of permissions with a particular code source. Protection domains are the basic concept of the default sandbox; they tell us things like code loaded from www.oreilly.com is allowed to read files on my disk, code loaded from www.sun.com is allowed to initiate print jobs, or code that is loaded from www.klflote.com and signed by Scott is allowed to do anything it wants. Policy files Policy files are the administrative element that controls the sandbox. A policy file contains one or more entries that define a protection domain; less formally, we can say that an entry in a policy file grants specific permissions to code that is loaded from a particular location andor signed by a particular entity. Programs vary in the way in which they define policy files, but there are usually two policy files in use: a global policy file that all instances of the virtual machine use and a user−specific policy file. Policy files are simple files that can be created and modified with a text editor, and the JRE comes with a tool policytool that allows them to be administered as well. Keystores Code signing is one way in which code can be granted more latitude. The rationale behind code signing is discussed in Chapter 7, but if you are assured that code you are running came from an organization that you trust, you may feel comfortable allowing that code to read the files on your disk, send jobs to the printer, or whatever. Signed code depends on public key certificates, and there is a lot of administration that takes place when you use certificates. The certificates themselves are held in a location usually a file called the keystore. If you are a developer, the keystore is consulted to find the certificate used to sign your code; if you are an end user or system administrator, the keystore is consulted when you run signed code to see who actually signed the code. In the next few sections, well look at these elements in more depth.

2.2 Permissions

Every Java class carries a set of permissions that defines the activities that the class is allowed to perform. The parameters of the sandbox are wholly defined by these permissions. When a Java program attempts to perform a sensitive operation, the permissions for all active classes are consulted: if every class carries the permission 22 to perform the operation, then the operation is permitted to continue. Otherwise, an exception is thrown in the code, and the operation fails. Which Permissions Apply