Managing policy codebases The policytool

Note that the keystore entry for this file is .keystore. You can change that value through an option under the Edit menu. You can add new codebases to this file by selecting the Add Policy Entry button; when you add a policy entry, you are allowed to specify a URL and a signer both of which are optional. The entry for the signer should be an alias in the keystore; if you enter a signer who is not in the keystore, youll get a warning, but the operation will continue. You may delete codebases by selecting one and pressing the Remove Policy Entry button. Selecting a codebase and pressing the Edit Policy Entry button allows you to edit the specific set of permissions for a codebase.

2.5.1.2 Managing permissions

When you press the Edit Policy Entry button, you get a window similar to that shown in Figure 2−2. This window lists all permissions that are associated with the given codebase and provides the opportunity to add or remove individual permissions. Figure 2−2. A set of permissions for a codebase The window where you add permissions contains three pulldown menus in which you can select the permission type, name, and actions. The list of permission types in the pulldown is limited to those defined in the core API; if you need to add a permission in an extension or a third−party package, you must enter the type explicitly. When you select a type, the pulldown for the permission target name changes to match valid names for the type. However, since many types accept arbitrary names, you often need to type the target name explicitly into the box; for example, when you select a socket permission, you must type the hostname andor port name explicitly. Even though policytool provides an administrative GUI for policy files, you still must be very familiar with the names of permissions as well as the targets and actions they accept.

2.5.2 Permissions Outside of Policy Files

Virtually all of the permissions granted to code comes from policy files. However, advanced applications are allowed to grant additional permissions to code that they load, and standard Java class loaders grant some additional permissions to every class that they load. Classes that are loaded from the filesystem are always granted permission to read files in the directory hierarchy from which they were loaded. Classes that are loaded via HTTP are always granted permission to establish a connection back to the host from which they were loaded; they are also granted permission to accept a connection from that host.

2.6 The Default Sandbox

And now, putting this all together, lets examine the default sandbox of various Java environments: Java applications For applications invoked via the Java command line, the sandbox is initially disabled. To enable the sandbox, you must specify the java.security.manager property like this: piccolo java −Djava.security.manager other args Applications may also enable the sandbox programatically by installing a security manager, as we discuss in Chapter 4. Once enabled, the security manager will use the two default policy files to determine the parameters of the sandbox. You can specify an additional policy file to be used with the java.security.policy property: piccolo java −Djava.security.policy=URL You can specify a full URL e.g., with an http: or file: protocol or simply list a filename. If you want the given policy file to be the only policy file used bypassing the ones in JREHOMElibsecurity and the users home directory, specify two equals signs: piccolo java −Djava.security.policy==URL Putting this all together, heres how we would run the class PayrollApp in the default sandbox with additional permissions loaded from the file java.policy in the local directory: piccolo java −Djava.security.manager \ −Djava.security.policy=java.policy PayrollApp Appletviewer Chapter 2. The Default Sandbox