Using Security Policies with RMI Policy Tool

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

You dont have to use a security manager with your RMI application. The only basic feature of RMI that wont work is dynamic classloading. However, both the RMI registry and the activation daemon do use security policies. If you use either of these services, and dont give them a special security policy, your application can break in subtle ways. Consider, for example, binding a server that uses custom sockets into the RMI registry. The RMI registry will contain an instance of the stub class that refers to the original server. This deserialized stub will have an associated socket. Since the associated socket is an instance of a custom socket class, this means that the calling stack for the constructor for java.net.socket contained a non-Javasoft class. This means that the bind will fail unless the RMI registry has been given a more relaxed set of permissions. Recall that the -J flag is used to pass arguments to the underlying JVM for both the RMI registry and the activation daemon. For example, you need to use a command line invocation such as: registry -J-Djava.security.policy= d:\classes Because dynamic classloading is useful, and because using the activation daemon or the registry often forces you to write one anyway, [ 3] RMI applications usually wind up with a set of associated security policies: one for the servers, one for the naming service and activation daemon, and one for the clients. [ 3] And because its the right thing to do.

20.4.4 Policy Tool

Java 2 comes with a simple GUI application, called policytool , that helps you edit policy files. You run it from the command line as follows: policytool The application allows you to open and edit a policy file, as shown in Figur e 20- 2 . Figure 20-2. The policytool application Each policy entry in the application corresponds to a single grant statement in the file. You can select an existing policy entry and then either edit it or remove it from the file, or you can create a new policy entry. In the case of either creating or editing a policy entry, you wind up using the Policy Entry panel, shown in Figur e 20- 3 . Choosing Add Entry or Edit Entry from this panel brings you to the Permissions panel see Figur e 20- 4 , which uses combo boxes to simplify the generation of individual permissions. Figure 20-3. Policy entry panel Figure 20-4. Permissions panel

20.4.5 Some Final Words