Programmers, system administrators, and end users all have different security concerns and, thus, different roles to play in the Java 1.2 security architecture.
System programmers are the people who define new Java APIs that allow access to sensitive system resources. These programmers are typically working with native methods that have unprotected access to the system. They need to use the Java access-control architecture to prevent untrusted code from executing those native methods. To do this, system programmers must carefully insert SecurityManager calls at appropriate places in their code. A system programmer may choose to use an existing Permission subclass to govern access to the system resources exposed by her API, or she may decide to define a specialized subclass of Permission.
The system programmer carries a tremendous security burden: if she does not perform appropriate access control checks in her code, she compromises the security of the entire Java platform. The details are complex and are beyond the scope of this book. Fortunately, however, system programming that involves native methods is rare in Java; almost all of us are application programmers who can simply rely on the existing APIs.
Programmers who use the core Java APIs and standard extensions, but do not define new extensions or write native methods, can simply rely on the security efforts of the system programmers who created those APIs. In other words, most of us Java programmers can simply use the Java APIs and need not worry about introducing security holes into the Java platform.
In fact, application programmers rarely have to use the access-control architecture. If you are writing Java code that may be run as untrusted code, you should be aware of the restrictions placed on untrusted code by typical security policies. Keep in mind that some methods (such as methods that read or write files) can throw SecurityException objects, but don't feel you must write your code to catch these exceptions. Often, the appropriate response to a SecurityException is to allow it to propagate uncaught, so that it terminates the application.
Sometimes, as an application programmer, you want to write an application (such as an applet viewer) that can load untrusted classes and run them subject to access-control checks. To do this in Java 1.2, you must first install a security manager:
System.setSecurityManager(new SecurityManager());
Then use java.net.URLClassLoader to load the untrusted classes. URLClassLoader assigns a default set of safe permissions to the classes it loads, but in some cases you may want to modify the permissions granted to the loaded code through the Policy and PermissionCollection classes.
In Java 1.2 and later, system administrators are responsible for defining the default security policy for the computers at their site. The default policy is stored in the file lib/security/java.policy in the Java installation. A system administrator can edit this text file by hand or use the policytool program from Sun to edit the file graphically. policytool is the preferred way to define policies, so the syntax of the underlying policy file is not documented in this book.
The default java.policy file defines a policy that is much like the policy of Java 1.0 and Java 1.1: system classes and installed extensions are fully trusted, while all other code is untrusted and only allowed a few simple permissions. While this default policy is adequate for many purposes, it may not be appropriate for all sites. For example, at some organizations, it may be appropriate to grant extra permissions to code downloaded from a secure intranet.
In order to define secure and effective security policies, a system administrator must understand the various Permission subclasses of the Java platform, the target and action names they support, and the security implications of granting any particular permission. These topics are explained well in a document titled "Permissions in the Java 2 SDK," which is part of the Java 1.2 release and also available (at the time of this writing) online at: http://java.sun.com/products/jdk/1.2/docs/guide/security/permissions.html.
Most end users do not have to think about security at all: their Java programs should simply run in a secure way with no intervention by them. Some sophisticated end users may want to define their own security policies, however. An end user can do this by running policytool himself to define personal policy files that augment the system policy. The default personal policy is stored in a file named .java.policy in the user's home directory. By default, Java loads this policy file and uses it to augment the system policy file.
In Java 1.2 and later, a user can specify an additional policy file to use when starting up the Java interpreter, by defining the java.security.policy property with the -D option. For example:
C:\> java -Djava.security.policy=policyfile UntrustedApp
This line runs the class UntrustedApp after augmenting the default system and user policies with the policy specified in the file or URL policyfile. To replace the system and user policies instead of augmenting them, use a double equals sign in the property specification:
C:\> java -Djava.security.policy==policyfile UntrustedApp
Note, however, that specifying a policy file is only useful if there is a SecurityManager installed. If a user doesn't trust an application, he presumably doesn't trust that application to voluntarily install its own security manager. In this case, he can define the java.security.manager system property:
C:\> java -Djava.security.manager -Djava.security.policy=policyfile UntrustedApp
The value of this property does not matter; simply defining it is enough to tell the Java interpreter to automatically install a default SecurityManager object that subjects an application to the access control policies described in the system, user, and java.security.policy policy files.
 |  |  |
| 5.4. Access Control |  | 5.6. Permission Classes |
Copyright © 2001 O'Reilly & Associates. All rights reserved.