he changes to Java’s security implementation have made it more robust and introduced more programmatic hooks for developers to add to Java’s default security mechanisms. Oddly, even with the introduction of Java Authentication and Authorization Services (JAAS) and its subsequent inclusion in the core API as of JDK 1.4, Java security still relies on a structured text format for its core configuration files: java.security and java.policy. While it is well known that there is a certain amount of overhead to parse XML files, the idiosyncratic layout of a security “grant block” in java.policy means that there are no standard tools to effectively verify its syntactic correctness at build time.

If your security needs are minor, your policy file simple, and your team is small, then it is unlikely that you view this as a serious shortcoming. However, if your environment and security needs are complex, and your team is fairly large then there is ample opportunity to inadvertently introduce syntactic errors into the java.policy file that won’t be recognized until runtime. While extending the Policy class to be backed by an XML file is an option, frequently Sun’s default implementation is what is relied upon and this leaves open the possibility of runtime issues arising with the java.policy file.

To remedy this situation, I coded a simple utility to check java.policy and let me know whether it is syntactically correct. The utility also prints out the specified permissions for each codebase of interest. This article will walk you through the code (download it here or from the link in the left-hand column) and discuss the utility’s function as well as some of the basics of Java 2 security.

As you read this article it will be helpful to have your java.policy and java.security files available. These two essential Java configuration files are located by default in the ${JAVA_HOME}/jre/lib/security directory. The security.policy file’s role with respect to permissions is that it allows you to specify the policy files that are to be consulted by your application. The permissions in the file URLs that are specified are cumulative, meaning that they are aggregated at runtime to create the full list of permissions allocated to your application(s). The two URLs noted by default are listed below and while there is some benefit to adhering to standard locations for your policy file there is nothing that prevents you from changing it.

policy.url.1=file:${java.home}/lib/security/java.policypolicy.url.2=file:${user.home}/.java.policy

A replacement location can be specified with the VM argument:

Djava.security.manager=C:your_policy_name.policy

Also note that while you can use the policy.url mechanism to specify multiple policy files you only need one and you can name it whatever you’d like.

The security.policy file is structured like a standard Java properties file, which makes it easier to manage and is less likely to change than java.policy. You’ll see too that many of the settings pertain to cryptography providers, the keystore, and the like. These aren’t the kinds of things that multiple developers are likely to modify.

One other setting in security.policy that is critical to the programmatic access to java.policy is the policy provider setting. This is the class that the audit utility must instantiate first to assemble the permissions for evaluation.

policy.provider=sun.security.provider.PolicyFile  

The code below is the typical way to get at the Policy file object.

pcoll = Policy.getPolicy().getPermissions(cs);

This call obtains the Policy file object and then the PermissionsCollection associated with it. More on this in a bit.

Activating the Security Manager
Before delving into the second critical configuration file, java.policy, I need to digress and point out that Java security isn’t “turned on” by default. Java’s security record is so remarkably good considering the ubiquity of Java code in the world today that many Java programmers don’t know or realize this. The manager of all security operations in Java 2 is the SecurityManager class and by default this class is deactivated. You can engage the SecurityManager in one of two ways. First, you can specify it on the command line at runtime:

java –Djava.security.manager   

Or you can programmatically activate it by instantiating a SecurityManager and calling it explicitly to perform the requisite security checks for your application.

Given the importance today of coding secure applications, Sun’s choice to leave this disabled by default is unfortunate to say the least. If you don’t turn on the Security Manager, java.policy isn’t consulted at all and your application will never throw an AccessException. Given this gap in many developer’s understanding of the Java security model it is certain that a lot of developers have been lulled into a false sense of security when in fact they have little or no security in place at all.

Setting Up Grant Blocks
Returning to the java.policy file, as mentioned previously, it is the second critical security configuration file in the default Java runtime environment and it is where permissions are configured. In Java, a Permission is configured in a grant block that is set up for a particular codebase. The first such grant in the default java.policy file provided by Sun is:

// Standard extensions get all permissions by defaultgrant codeBase "file:${java.home}/lib/ext/*" {	permission java.security.AllPermission;};

This grant allows any code installed in the /ext directory to have all permissions, literally. This is why fighting classpath problems by hoisting your code up the classloading delegation ladder into the /ext directory is so dangerous. Code living in this directory has rights to modify system properties and interact with the file system or do anything else you can think of on your system.

Note that Sun’s ‘codeBase’ is specified as a URL and supports the asterisk ( * ) wildcard. If you neglect a quote, a curly brace, or the final semicolon (;) your Permission file won’t be parsed and read properly at runtime (which is obviously why we’re going to verify its format at build time).

All permissions specified in java.policy adhere to the same basic format but may have an additional action modifier appended to them such as in the following example.

// com.tillman.util.security.permissionchecker package is in this directorygrant codeBase "file:/C:/eclipse/workspace/Permissions/PermissionReader/bin/*" {	permission java.security.SecurityPermission "getPolicy";	permission java.io.FilePermission "<>", "read,write,execute,delete";	permission java.net.URLPermission "http://www.nytimes.com", "listen, connect";};

The first permission in the block above is essential because the audit utility needs to get a reference to the Policy object in order to check its permissions so this must be explicitly permitted in the policy file. Obviously, you’ll need to modify the file URL to point to where you’ve placed the audit utility.

The code that checks the permissions is fairly straightforward. The only twist I’ve put in is that I want to be able to specify the codebases to audit in a properties file. This gives me the flexibility to ignore the default Java grant blocks. (You’ll note though that in the output these default blocks are appropriately added to the permissions that are of interest to me). The getFileLocations( ) method in the audit code simply returns a list of the codebases specified in my properties file (note the double backslashes to escape the backslash character on Windows).

From within a while loop, each of the locations specified in my properties file is converted to a codebase URL.

codebase = new File((String)iter.next()).toURL();

Each codebase is then passed as an argument to the CodeSource constructor. The CodeSource is effectively the “key” that the Policy object uses to retrieve the PermissionCollection.

cs = new CodeSource(codebase, null);pcoll = Policy.getPolicy().getPermissions(cs);

The PermissionCollection pcoll variable’s members are returned as an enumeration using the elements( ) method. Finally, we iterate through the enumeration and use each retrieved Permission object’s toString( ) method to print out its name.

enum1 = pcoll.elements();for (; enum1.hasMoreElements(); ) {    		System.out.println((Object)enum1.nextElement());}

The output displays something like this:

path: /C:/eclipse/workspace/Permissions/TestTwo/bin(java.util.PropertyPermission java.version read)(java.util.PropertyPermission java.vm.name read)

If the syntax of any of the permission grant blocks?or the permissions themselves?prove to be incorrect then the utility will display a message describing the parse error. In truth, the call to get the Policy object will blow up in this way without the rest of the code running. Nevertheless, the utility’s listing of the aggregation of the permissions for each codebase will give you another opportunity to confirm that the security you’re implementing is as desired.

Once you activate the SecurityManager the flexibility and power of the Java 2 security architecture is at your disposal. While the java.policy and java.security file formats would perhaps be better implemented as conventional XML files they are still fairly readable and manageable. Moreover, as you’ve seen, the java.policy file can be checked at build time to avoid unexpected runtime security lapses or failures. The Java Policy object can be extended to tailor its behavior to better meet your needs but the standard configuration options are adequate for most security needs.