43.

  

Removing AllPermission

Setting the security access to AllPermission is easy and removes all possible security issues that may hinder development of a Jini application. However, it leaves your system open , so you must start using a more rigorous security policy at some stage ”hopefully before others have damaged your system. The problem with moving away from this open policy is that permissions are additive rather than subtractive . That is, you can't take permissions away from AllPermission; you have to start with an empty permission set and add to that.

Not giving enough permission can result in at least three situations when you try to access something:

• A security- related exception can be thrown. This is comparatively easy to deal with, because the exception will tell you what permission is being denied . You can then decide if you should be granting this permission or not. Of course, this should be caught during testing, not when the application is deployed!
• A security-related exception can be thrown but caught by some library object, which attempts to handle it. This happens within the multicast lookup methods , which make multicast requests . If this permission is denied, it will be retried several times before giving up. This leads to a cumulative time delay before anything else can happen. The application may be able to continue, and it will just suffer this time delay.
• A security-related exception can be thrown but caught by some library object and ignored. The application may be unable to continue in any rational way after this, and may just appear to hang. This may happen if network access is requested but denied, and then a thread waits for messages that can never arrive . Or it may just get stuck in a loop

The first two cases will occur if permissions are turned off for the service providers, such as in the rmi.FileClassifierServer of Chapter 8 if insufficient permissions are given.

There is a java.security.debug system property that can be set to print information about various types of access to the security mechanisms. This can be used with a slack security policy to find out exactly what permissions are being granted. Then, with the screws tightened, you can see where permission is being denied. An appropriate value for this property is access , as in

 java -Djava.security.debug=access ... 

For example, running client.TestFileClassifier with few permissions granted may result in a trace such as the following:

 ... access: access allowed (java.util.PropertyPermission socksProxyHost read) access: access allowed (java.net.SocketPermission 127.0.0.1:1174 accept,resolve) access: access denied (java.net.SocketPermission 130.102.176.249:1024 accept,resolve) access: access denied (java.net.SocketPermission 130.102.176.249:1025 accept,resolve) access: access denied (java.net.SocketPermission 130.102.176.249:1027 accept,resolve) ... 

The denied access is an attempt to make a socket accept or resolve request on my laptop (IP address 130.102.176.249), probably for RMI-related sockets. Since the client just sits there indefinitely making this request on one random port after another, this permission needs to be opened up, because the client otherwise appears to just hang.