Policytool

In JAAS, and many of the other engine classes, a security policy file is used to define the permissions for classes.

Cross-Reference

Some of these permissions are described in Chapter 19.

The policytool utility is used so that the user need not edit the policy file in a text editor, but can edit it using a standardized menu to help the user understand the fields and check the validity of the policy file. When a Java Virtual Machine (JVM) is initialized to run a Java program, the JVM needs to check its local policy settings to understand the permission set that it uses to run the Java program. The JVM's java.policy is defaulted to the {$JREHOME}/lib/security/java.policy file. This file is commonly known as the "system" policy file that grants permissions to standard extensions and allows access to system properties and to nonprivileged ports.

In the following example, where the local Java Runtime Environment (JRE) is located in the D:\jdk1.4\jre directory, the policy tool will look like Figure 8-1.

Figure 8-1: Policy tool loaded

The example policytool was started using the policytool -file D:\jdk1.4\jre\lib\security\java.policy command line. If no file name is specified during the startup of the policytool , it looks for the file called .java.policy under the user's home directory $HOME . Editing the policy file by hand is also possible; however, the policytool will catch mistakes that editing it by hand will not. The jdk1.4 policy file, which is distributed, contains the entries in Listing 8-9.

Listing 8-9: jdk1.4 policy file entries

 // Standard extensions get all permissions by default     grant codeBase "file:${java.home}/lib/ext/*" {     permission java.security.AllPermission; };     // default permissions granted to all domains     grant {      // Allows any thread to stop itself using the java.lang.Thread.stop()     // method that takes no argument.     // Note that this permission is granted by default only to remain     // backwards compatible.     // It is strongly recommended that you either remove this permission     // from this policy file or further restrict it to code sources     // that you specify, because Thread.stop() is potentially unsafe.     // See "http://java.sun.com/notes" for more information.     permission java.lang.RuntimePermission "stopThread";         // allows anyone to listen on un-privileged ports     permission java.net.SocketPermission "localhost:1024-", "listen";         // "standard" properies that can be read by anyone         permission java.util.PropertyPermission "java.version", "read";     permission java.util.PropertyPermission "java.vendor", "read";     permission java.util.PropertyPermission "java.vendor.url", "read";     permission java.util.PropertyPermission "java.class.version", "read";     permission java.util.PropertyPermission "os.name", "read";     permission java.util.PropertyPermission "os.version", "read";     permission java.util.PropertyPermission "os.arch", "read";     permission java.util.PropertyPermission "file.separator", "read";     permission java.util.PropertyPermission "path.separator", "read";     permission java.util.PropertyPermission "line.separator", "read";         permission java.util.PropertyPermission "java.specification.version", "read";     permission java.util.PropertyPermission "java.specification.vendor", "read";     permission java.util.PropertyPermission "java.specification.name", "read";         permission java.util.PropertyPermission "java.vm.specification.version", "read";     permission java.util.PropertyPermission "java.vm.specification.vendor", "read";     permission java.util.PropertyPermission "java.vm.specification.name", "read";     permission java.util.PropertyPermission "java.vm.version", "read";     permission java.util.PropertyPermission "java.vm.vendor", "read";     permission java.util.PropertyPermission "java.vm.name", "read"; };

Notice that this policy file grants permissions to all users, but it does provide the codebase in the first policy entry. This file has two policy entries: CodeBase "file:${java.home}/lib/ext/" and CodeBase<ALL> . A codebase is the location of the code that requires the access permissions. It can be any type of URL, and because it is a URL, it requires forward slashes . The first entry specified in the policy file maps to the codebase for the java extension JARs. In this case, the ${java.home} specifies the D:\jdk1.4 java installation directory; therefore, the rest of the codebase will map to the D:\jdk1.4\lib\ext\ directory for any Java extensions that are supplied for the library.

This entry grants all users all access to that subdirectory during the runtime of the JVM. The principal can be specified to grant a particular user access to the target resource. This can be added when editing a specific policy entry. Figure 8-2 shows how a principal entry can be added, edited, or removed.

Figure 8-2: The principal entry

After you select a particular permission class, it can also be edited. One of the benefits of using the policytool is that it gives the editor the exact selections that are available without having to look them up in a permissions class. Figure 8-3 shows which actions are selectable for the FilePermission .

Figure 8-3: The Permission class

When the Edit/Change Keystore menu is selected, the Keystore entry, as shown in Figure 8-4, appears. The input that is needed in this window is the keystore URL and the keystore type, which will only allow the one entry into the policy file.

Figure 8-4: The Keystore entry

The policytool formats the policy file based on the rules of the policy file. It gives the editor direction on what is allowed into the policy file. This prevents the editor from making mistakes to the file. If the file already contains an error, the policytool displays a warning log if the severity is not too high, or it states the reason that the file cannot be parsed. It has been mentioned that many developers edit these files by hand, but then they may discover errors in the file only during runtime. The policytool guarantees the validity of the file before the execution of the application. This can save a lot of time and effort in troubleshooting an application.

You can use the policytool to grant permissions to local resources. For instance, you may want to grant an applet read/write access to a local directory or file. One way to accomplish this is to add a policy entry with a principal. Refer to Figure 8-2. You may want to require the code to be originated from a specific location (by using the CodeBase option in the policy tool). Also, you may require the code to be signed (by using the SignedBy text box in the policy tool). For example, you may want to require the code to be signed if you are interested in a trusted applet. To add a principal in the policy tool, you select the Add Principal button (in the Policy Entry dialog box) and select a principal type, such as X500Principal, which displays the complete principal type (like com.sun.security.auth.X500Principal ). Next, you enter the principal name (such as CN=TEST,OU=ORG,O=MYCOMPANY,C=US ). Finally, you must save your settings.

Tip	In order for an applet to access a resource - or for that matter any application running with a security manager - the corresponding permission must be explicitly granted to the code attempting the access.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Project Management JumpStart

Absolute Beginner[ap]s Guide to Project Management

Introduction to 80x86 Assembly Language and Computer Architecture

Web Systems Design and Online Consumer Behavior

Programming .Net Windows Applications

Digital Character Animation 3 (No. 3)