Providing Your Own Security Manager

Writing a Security Manager

To write your own security manager, you must create a subclass of the SecurityManager class. Your SecurityManager subclass overrides various methods from SecurityManager to customize the verifications and approvals needed by your Java application.

This page will walk through an example security manager subclass that restricts certain Thread accesses. The following is a list of ThreadGroup methods that use the security manager to approve the operation before proceeding.

• ThreadGroup(ThreadGroup parent, String name)
• setDaemon()
• setMaxPriority()
• stop()
• suspend()
• resume()
• destroy()

And the following is a list of Thread methods that use the security manager to approve the operation before proceeding.

• all constructors
• stop()
• suspend()
• resume()
• setPriority()
• setName()
• setDaemon()

To get approval from the security manager these methods call the security manager's checkAccess() method. If the security manager approves the operation then checkAccess() returns, otherwise checkAccess() throws a SecurityException.

Thus, our example SecurityManager subclass that wishes to impose a stricter policy on Thread accesses, must override SecurityManager's checkAccess() method. SecurityManager provides two versions of checkAccess(): one that takes a Thread argument and one that takes a ThreadGroup argument. Each of these methods verifies whether the current thread is allowed to perform one of the restricted methods on the argument. A policy frequently implemented by browsers is that a thread or thread group can only modify another thread or threadgroup if they are in the same group.

The policy implemented by our example prompts the user for a password. If the password is correct then the access is allowed. While this is an unlikely policy for a real application concerned with thread accesses, it does provide some visual feedback as to when the SecurityManager is invoked to approve thread accesses and illustrates the point none-the-less.

All security managers must be a subclass of SecurityManager. Thus, our SecretPasswordSMgr class extends SecurityManager.

class SecretPasswordSMgr extends SecurityManager {
    . . .
}

Next, SecretPasswordSMgr declares a private instance variable password to contain the password that the user must enter in order to allow the restricted thread accesses. The password is set upon construction:

SecretPasswordSMgr(String password) {
    super();
    this.password = password;
}

The next method in the SecretPasswordSMgr class is a private helper method named accessOK(). This method prompts the user for a password and verifies it. If the user entered an valid password the method returns true, false otherwise.

private boolean accessOK() {
    int c;
    DataInputStream dis = new DataInputStream(System.in);
    String response;

    System.out.println("What's the secret password?");
    try {
        response = dis.readLine();
        if (response.equals(password))
	    return true;
        else
	    return false;
    } catch (IOException e) {
        return false;
    }
} 

Finally at the end of the SecretPasswordSMgr class are the two overriden checkAccess() methods:

public void checkAccess(Thread g) {
    if (!accessOK())
        throw new SecurityException("Not!");
}
public void checkAccess(ThreadGroup g) {
    if (!accessOK())
        throw new SecurityException("Not Even!");
}

Both checkAccess() methods call accessOK() to prompt the user for a password. If access is not OK, then checkAccess() throws a SecurityException. Otherwise, checkAccess() returns normally. Note that SecurityException is a runtime exception, and as such does not need to be declared in the throws clause of these methods.

Note that the checkAccess() method does not know which restricted thread accesses is being attempted. It must make the decision to approve or disapprove the access based solely on the current thread and the thread or thread group passed into the method.

checkAccess() is just one of many of SecurityManager's checkXXX() methods that verify various types of accesses. You can override any number of checkXXX() methods to implement your security policy. You do not need to override all of SecurityManager's checkXXX() methods, just the ones that you want to customize. The default behaviour for the checkXXX() is quite lenient and thus should be sufficient for your needs if you aren't interested in overriding them explicitly.

All of SecurityManager's checkXXX() methods operate in the same way:

• If access is allowed, the method returns.
• If access is not allowed, the method throws a SecurityException.

Make sure that you implement your overriden checkXXX() methods in this manner.

Well, that's it for our SecurityManager subclass. As you can see implementing a SecurityManager is simple. You just:

• Create a SecurityManager subclass
• Override a few methods

The trick is determining which methods to override and implementing your security policy. More About the SecurityManager Class will help you figure out which methods you should override depending on what types of operations you'd like to protect. The next page shows you how to install the SecretPasswordSMgr class as the security manager on-duty for your Java application.

See also

java.lang.SecurityManager
java.lang.SecurityException

Providing Your Own Security Manager