Inside a Policy File

The application-specific policy file is defined using the java.security.policy system parameter. That is, to set the application-specific policy, you would use a command line such as: java -Djava.security.policy=d:\java.policy Without a security manager, however, this doesnt have much meaning. If a JVM is invoked with a security policy, its fairly common to install a security manager from the command line as well, as in the following example: java -Djava.security.manager -Djava.security.policy=d:\java.policy There is one rather unexpected wrinkle in the java.security.policy system parameter. You can set it using == instead of = . That is, the following command line is perfectly valid: java -Djava.security.manager -Djava.security.policy==d:\java.policy This will instruct the JVM to use only the application-specific permissions file and ignore the other two permissions files. This has the effect of tightening the sandbox and can be useful during development, when you want to make sure youve figured out the correct security policy for your application, and when dealing with code you really dont trust, such as an application that you just downloaded from the Internet.

20.4.2 Inside a Policy File

A policy file consists of a sequence of grant statements. Each grant statement has the following format: grant [signedBy Name] [codeBase URL] { list of permissions } ; This translates to the following sentence: Any class that was loaded from the codebase specified by URL , and was digitally signed by Name , has the following permissions. Square brackets indicate optional elements, and the words signedBy and codeBase are literals that must be used in front of their arguments. Thus, the following are all valid grant statements: grant { list of permissions } ; grant codeBase http:www.oreilly.com{ list of permissions } ; grant signedBy WGrosso{ list of permissions } ; grant signedBy WGrosso codeBase http:www.oreilly.com{ list of permissions } ; We will skip over digitally signing code. Its complicated, and managing a keystore, while important, is outside the scope of this book. For more information on this and other advanced aspects of security, see Applied Cryptography: Protocols, Algorithms, and Source Code in C, Second Edition by Bruce Algorithms, and Source Code in C, Second Edition by Bruce Schnier John Wiley Sons. The curly braces contain a comma-delimited list of permissions in the ASCII format I described earlier. Here, for example, is a grant statement that can run all the example programs in this book, provided the class files are installed in the correct location: grant codeBase file:d:classes { permission java.awt.AWTPermission accessClipboard; permission java.awt.AWTPermission accessEventQueue; permission java.awt.AWTPermission listenToAllAWTEvents; permission java.awt.AWTPermission showWindowWithoutWarningBanner; permission java.awt.AWTPermission readDisplayPixels; permission java.net.SocketPermissi on :1024-, accept, connect, listen, resolve; permission java.io.FilePermission ALL FILES, read; permission java.io.FilePermission ALL FILES, write; permission java.io.FilePermission ALL FILES, delete; permission java.util.PropertyPermission , read, write; }; This allows any class located in a subdirectory of D:\classes to manipulate the GUI, create socket connections on nonsystem ports, manipulate files, and edit the system properties object. It does not, however, extend any permissions to dynamically loaded classes that come over the wire. As such, its a perfectly good policy for both the server-side where dynamically loaded classes are rarely used and static clients. It would not, however, work in a scenario where the client dynamically downloads classes from the server.

20.4.3 Using Security Policies with RMI