Chapter 6: Implementing Security Policies

6.4. Running Secure Applications

In Chapter 1, "Java Application Security" we showed how JavaRunner and the Launcher can be used to run a Java application. Now that we have the final piece of the security policy story, we can put everything together and show how the policy applies to these applications.

6.4.1. The Secure JavaRunner Program

Running a program securely under the auspices of JavaRunner requires that we modify that program to accept a security manager:

Class Definition

public class JavaRunner implements Runnable {
	.. other methods are unchanged ..

	public static void main(String args[])
									throws ClassNotFoundException {
		Class self = Class.forName("JavaRunner");
		System.setSecurityManager(new JavaRunnerManager());
		JavaRunnerLoader jrl = new JavaRunnerLoader(
									args[0], self.getClassLoader());
		ThreadGroup tg = jrl.getThreadGroup();
		Thread t = new Thread(tg,
				new JavaRunner(jrl, args[1], getArgs(args)));
		t.start();
		try {
			t.join();
		} catch (InterruptedException ie) {
			System.out.println("Thread was interrupted");
		}
	}
}

This single-line change installs a security manager for us; the security manager provides the security policy for the target application. Because our security manager defers most of its checks to the access controller, we must have appropriate java.policy files somewhere (unless, of course, we have installed a different default Policy class). If these policy files are in the default locations ($JAVAHOME/lib/security/java.policy and $HOME/.java.policy), no other steps are necessary. If that file is somewhere else, you must list that file in the java.security file as an alternate policy URL.

Note that we cannot use the -Djava.security.policy command-line argument: the -Djava.security.policy command-line argument installs the Launcher's security manager for us, which prevents our security manager from being installed. On the other hand, we could forego the use of the JavaRunnerManager class altogether and use the same security manager that the Launcher uses by specifying the -Djava.security.policy command-line argument.

In Java 1.2, installing this security manager has other ramifications upon the JavaRunner program. Since the JavaRunner class is loaded from the default URL class loader, it is subject to the permissions of the access controller. As a practical matter, this means that one of the java.policy files must have certain permissions in it that the JavaRunner program needs: it needs to open sockets (to open the URLs from which to retrieve the classes), create a class loader, and so on. The simplest way to achieve this is to put the JavaRunner class and its associated class files (the class loader and security manager it uses) into a single directory and grant all permissions to that directory. If, for example, we put those files into the /home/sdo/JavaRunner directory, we would need to put this entry into a java.policy file:

Class Definition

grant codeBase "file:/home/sdo/JavaRunner" {
	permission java.security.AllPermission;
};

6.4.2. The Secure Java Launcher

In 1.2, when you run a program via the command line, no security manager is installed for you and the program has no sandbox (unless one is installed as we did for the JavaRunner program).

However, when you specify the -Djava.security.policy argument on the command line, a default security manager is installed; the effect of that argument is to install the Launcher's security manager. This security manager in turn initializes the access controller--as we mentioned in Chapter 5, "The Access Controller", the access controller is not initialized until it is first used, and it will not be used until the security manager calls it (unless, of course, your own code calls it). The Launcher's security manager asks the access controller to check for the appropriate permission (that is, the permission that we listed in Table 6-3) with the exceptions that we listed with that table and the additional exception that the checkExit(), checkPackageAccess(), and checkPackageDefinition() methods always succeed.

Remember when you use the Launcher that the security provisions only apply to classes that are loaded from the CLASSPATH and not from the Java API.

6.3. Implementation Techniques		6.5. Summary

Copyright © 2001 O'Reilly & Associates. All rights reserved.