Keystores The Default Sandbox

running the program. Administration of the keystore is handled by the keytool utility see Chapter 10. By default, the keystore is held in a file called .keystore in the users home directory. When you install a public key certificate into the keystore, you give that certificate an alias that is used to look up the certificate in the future. For example, my public key certificate lists my full name and other identifying information, but you may enter it into your keystore with an alias of sdo. This alias is the information that you list in a policy file.

2.4 Code Sources

Code sources are a combination of codebases and signers. The signer field must match the alias listed in the keystore, as weve just described. Codebases can be any valid URL. Because they are URLs, codebases always use forward slashes, even if the code is being read from the filesystem: file:C:filesjdk1.3 is the correct specification for the directory C:\files\jdk1.3\ although remember that if the drive is the default drive, you can leave it out and specify the URL as file:filesjdk1.3 . Codebases can use property substitution much like we showed when discussing file properties. Hence, the codebase for the Java extension directory can be universally specified as file:{java.home}libext. This trick applies somewhat to the classpath: if you want a particular set of permissions to apply to all classes on the classpath then you can use the codebase file:{java.class.path}. However, this works only when there is a single directory or JAR file in the classpath since only those cases result in a correct URL. The ending of the codebase URL is very important. There are four cases: The URL specifies a jar file http:www.sun.comsdosdoapp.jar. Only the classes in the jar file belong to the codebase. • The URL ends with a slash http:www.sun.comsdo. Only class files in the given directory belong to the codebase. Jar files in the given directory do not belong to the codebase. • The URL ends with an asterisk http:www.sun.comsdo. Both jar files and class files in the given directory belong to the codebase. However, jar and class files in subdirectories of the URL do not belong to the codebase. • The URL ends with a hyphen http:www.sun.comsdo−. All jar and class files in the given directory and its subdirectories belong to the codebase. • Note this directory syntax is not affected by package names. If you want to give permissions to the class com.sdo.PayrollApp , you list the directory in which the com subdirectory appears e.g., http:www.sdo.net, not http:www.sdo.netcomsdo.

2.5 Policy Files

In order to administer the Java sandbox, you list the various permissions weve discussed in a Java policy file. Java virtual machines can use any number of policy files, but there are two that are used by default. There is a global policy file named JREHOMElibsecurityjava.policy that is used by all instances of a virtual machine on a host. We consider this to be a global policy file because it allows an environment where the JRE is mounted from a common server by several machines; each of these machines will share the definitions in this file. In addition, there is a user−specific policy file called .java.policy that may exist in each users home directory HOME on UNIX systems, C:\WINDOWS on single−user Windows 98 systems, and so on. The set of permissions given to a program is the union of permissions contained in the global and user−specific policy files. Policy files are simple text files. You can administer them with policytool , or you can edit them by hand. Hand editing is discouraged in 1.3, policytool writes a warning at the top of the file not to edit it by hand, but real programmers still edit them by hand. Policy files are also used with JAAS, in which case their syntax changes slightly and you must edit them by hand at least until 1.4, when JAAS becomes integrated with the SDK. So first, well see how they look, and then well look at how they are created with policytool . Heres how a typical policy file might look: keystore {user.home}{}.keystore; Grant these permissions to code loaded from OReilly, regardless of whether the code is signed. grant codeBase http:www.oreilly.com { permission java.io.FilePermission tmp, read; permission java.lang.RuntimePermission queuePrintJob; }; Grant these permissions to code loaded from Sun but only if it is signed by sdo. grant signedBy sdo, codeBase http:www.sun.com { permission java.security.AllPermission; }; Grant these permissions to code signed by jra, no matter where it was loaded from grant signedBy jra { permission java.net.SocketPermission :1024−, accept, connect, listen, resolve; }; Grant these permissions to any code, no matter where it came from or whether it is signed grant { permission java.util.PropertyPermission java.version, read; }; Note how the policy file combines all the elements of the sandbox: the code sources the combination of signedBy and codeBase elements are associated with various permissions to create protection domains; the entire file is subject to the given keystore. The first line of this example tells the virtual machine to consult the keystore in the file HOME.keystore when it needs to check the certificates of entities that have signed code. The next four blocks of text define protection domains: code that is loaded from OReillys web site has permission to read files in tmp and to start a print job; code that is signed by sdo and loaded from Suns web site has permission to do anything it wants to; code that is signed by jra is able to operate on any nonprivileged socket; and all code is allowed to read the java.vendor system property. In each of these blocks, the syntax is the same: the word grant is followed by a code source and then a set of permissions enclosed by braces. The code source is composed of a codebase and a signer, either of which may be blank.