Don't wait until runtime to discover that there's a syntax error in java.policy. Use a simple utility to check java.policy at build time to avoid unexpected runtime failures.

WEBINAR:

On-Demand

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:

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.

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.

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.

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.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date