8.3 Java Security Policy

The basic Java 2 security model establishes that a Java system administrator can grant Permission s to a given program, based on the location from which the program is coming and the entities that signed the code. This is done in a declarative way, externally to applications. Although Java programmatic security is possible by using the API available in the package java.security and in its subpackages, the JRE has been designed to offer declarative security. Configuring the policy can be done externally to programs, which makes the programming task much easier. The advantage is that security-unaware programs are platform independent. In addition, an application's security policy can be easily changed without having to rewrite the application code every time. Therefore, declarative security should always be the preferred choice when configuring the security policy of a Java application, and programmatic security should be used only when declarative security alone is insufficient.

The Java 2 reference implementation uses flat files, called policy files , for policy configuration. Even if the default policy implementation is file based, application developers can implement their own java.security.Policy subclass, providing an implementation of its abstract methods . For example, a Policy implementation more sophisticated than a flat file could be an encrypted file.

A policy file contains a number of grant entries, whose syntax is specified in Listing 8.1.

Listing 8.1. Policy File grant Entry Syntax

 grant [signedBy  signers  ][, codeBase  URL  ] { permission  Perm_class  [  target  ][,  action  ][, signedBy  signers  ]; [permission ...] }; 

The policy file fragment in Listing 8.2 grants the FilePermission to read the file C:\AUTOEXEC.BAT from the local file system and the RuntimePermission to set a new SecurityManager to all the programs coming from the IBM Web site and signed by both the entities whose aliases are bob and alice . Note that the Permission class name must be fully qualified.

Listing 8.2. Example of Policy File grant Entry

 grant signedBy "bob, alice" codeBase "http://www.ibm.com" { permission java.io.FilePermission "C:\AUTOEXEC.BAT", "read"; permission java.lang.RuntimePermission "setSecurityManager"; }; 

For this policy fragment to have an effect, it is necessary that the keystore used by the JVM at runtime contain the digital certificates belonging to the entities whose aliases are bob and alice . At runtime, the digital signatures on programs downloaded from the IBM Web site are checked by using the public keys embedded in those certificates.

Note that the syntax of the grant entries must be followed exactly; the omission of even a single comma will result in rejection of the policy by the JVM. An inadvertent mistake editing the policy file may cause unexpected changes in the Java security policy, which, in turn , may compromise the security of the whole system. Additionally, in future Java versions, the default policy file may be encrypted or may be stored in a format other than a flat file, which will make manual editing of the policy impractical . For these reasons, the Policy Tool is the recommended utility to create and modify policy files. This tool prevents errors that are likely to happen when manually editing the text of policy files; in the future, this tool will be essential in updating nontext policy data.

8.3.1 Combining Multiple Signers

According to Listing 8.2, both bob and alice must have signed the code if a restricted action is initiated ”a logical AND . If the purpose had been to have the code signed by bob or alice , the grant entry should have been duplicated , once for bob and once for alice ”a logical OR . This concept is shown in Figure 8.5.

Figure 8.5. Combining Signers in the Policy File

The possibility for multiple signers to sign the code is very powerful. For example, one could grant Permission s to a particular piece of code only if this is signed by the developer who wrote the code and the company for which the developer works. Or, in a joint project between two companies, it may make sense for both companies to sign the code they produced.

8.3.2 Multiple Policy Files, One Active Policy

Multiple policy files can be combined at runtime to form a single Policy object, which represents the current security policy in effect. There is no risk of conflict, as Permission s in Java are only positive; by default, a program is denied any Permission , and through security policy configuration, users and system and network administrators can grant programs positive Permission s to access particular system resources. Once the runtime Policy object has been instantiated , a change in the policy configuration can be enforced by calling its refresh() method.

In addition, in a multiuser system, the user -defined policy file can be combined with a systemwide policy file and, in an intranet, even with a corporatewide policy file, which can be downloaded from a policy server using one of the network protocols implemented in the JVM. It is therefore very important to guarantee policy file portability. To accomplish this result, policy file values that could prevent portability can be replaced with special variables . For example, in a multiuser system, the user home directory changes user by user. In order for a grant entry in the systemwide policy file to specify the Permission to read a particular file from the user's home directory, policy files can use the variable ${user.home} . Similarly, when a policy file is downloaded from a policy server at runtime, portability problems may arise if some JVMs are running on Microsoft Windows operating systems, in which the file separator is a back slash, whereas others are running on UNIX systems, in which the file separator is a forward slash. To solve this problem, the Java language introduced the variable ${/} , or ${file.separator} , which at runtime is replaced with the file separator specific to the operating system. The presence of such variables in the policy file guarantees policy file portability and promotes the use of declarative security in place of programmatic security for Java applications.