How a Security Manager Works java.security.debug

Using the system property to install a security manager is often very convenient. For example, when I download Java applications from the Internet, I always install a security manager from the command line. Doing this helps limit the damage a malicious or poorly written program can cause. You can also use the java.security.manager parameter to specify a particular security manager, as in the following example: java -Djava.security.manager =java.rmi.RMISecurityManager application Ordinarily, however, when you write an RMI application, you include a security manager by calling System.setSecurityManager , as in the following line of code: System.setSecurityManagernew RMISecurityManager The reason for this is simple: RMIs dynamic classloading features wont work unless your application has an instance of SecurityManager installed. If you use dynamic classloading, relying on the user, or a batch file, to install an instance of SecurityManager is a bad idea. RMI provides a simple security manager, named RMISecurityManager , in the java.rmi package. In Java 2, RMISecurityManager simply subclasses the standard security manager without adding any functionality at all. Most RMI applications use RMISecurityManager or a custom subclass of it for two very simple reasons. First, using RMISecurityManager instead of the standard security manager effectively documents why the security manager was installed and thus makes it less likely that someone will modify the code to remove the security manager without thinking. Second, it automatically allows code to evolve as RMIs security model gets more elaborate; if you use an instance of RMISecurityManager , then when the RMISecurityManager s implementation becomes more sophisticated, your code will automatically evolve.

20.3.2 How a Security Manager Works

As Ive already indicated, a security manager works via a call-in policy. In other words, it relies on the Javasoft libraries to ask permission whenever a questionable operation is about to occur. The security sequence is: 1. A method that requires a security check is called. 2. As part of the implementation of that method, a call is made to the security manager. This call either throws an exception, indicating that a security violation has occurred, or returns silently, allowing the original method invocation to proceed. The Javasoft implementations of SecurityManager actually do quite a bit of work in order to check whether an operation is allowed or not. They start by checking whether the object calling SecurityManager has the appropriate permission. Note that since the object calling SecurityManager is almost certainly part of the standard Java libraries, it has permission by default. All classes that are part of the standard Java libraries have permission to perform any operation. However, they need to check whether they can actually perform the requested operation or not. After this, SecurityManager traverses the stack, checking to see whether each class in the stack trace has the appropriate permissions. If any of them do not, the check fails and SecurityManager throws an exception. Checking the stack is an important part of the security mechanism. Unless the entire stack is checked, theres really no way to prevent hostile code from initiating an action indirectly.

20.3.3 java.security.debug

You can watch SecurityManager at work by setting the java.security.debug system property. This property takes the following four basic values: all , access , policy , scl . Of these, access is the value that causes information about permissions checks to be printed to System.err . access also has three advanced versions: stack , domain , and failure . access stack causes the calling stack to be printed out every time a permission is checked. access domain prints out the domains of all the objects in the stack trace. access failure , the most useful of all the flags, prints out the stack and the class domain for the class that failed the security check when a failure occurs. For example, invoking our banking application via the following command- line invocation gives us an overwhelming amount of information about which permissions are being checked and from where in our application: [ 2] [ 2] This can be very useful when trying to build a security policy. Well discuss this in the next section. java -Djava.security.manager -Djava.security.debug=access daomin com.ora.rmibook. chapter9.applications.BankClient

20.4 Setting Up a Security Policy