SEC11-J. Define custom security permissions where required

The default SecurityManager checks whether the caller of a particular method has sufficient permissions to proceed with an action. An action is nothing but a level of access, for instance, actions for java.io.FilePermission are "read", "write", "execute", and "delete". [[Sun 06]] Permission Descriptions and Risks enumerates the default permissions associated with the restricted methods.

At other times, stronger confinement is necessary and custom permissions prove to be more suitable in assuming the role of privilege separators. Failure to provide custom permissions in the absence of the corresponding default permissions can lead to privilege escalation vulnerabilities wherein untrusted callers can execute restricted operations or actions.

Noncompliant Code Example

This noncompliant example is culpable on at least one count. It contains a privileged block that is used to perform two sensitive operations. First, loading a library and the second being setting the default exception handler. Fortunately, when the default security manager is used, it does not permit loading the library unless the RuntimePermission "loadLibrary.awt" is granted in the policy file. Quite deplorably, the programmer does not guard a caller from performing the second sensitive operation - setting the default exception reporter. This security weakness can be exploited, for example, by setting the verbosity of the handler to high so that the privilege separation mechanism envisioned by the rightful observers of the log files or error messages, is broken. This example also violates the advice of SEC01-J. Be careful using doPrivileged by using a privileged block for carrying out operations of varying natures.

class LoadLibrary {
  private void loadLibrary() {
    AccessController.doPrivileged(new PrivilegedAction() {
      public Object run() {
        // privileged code
        System.loadLibrary("awt");
        // perform some sensitive operation like setting the default exception handler
        MyExceptionReporter.setExceptionReporter(reporter); 
        return null; 
      }
    });		  
  }
}

Compliant Solution

Define a custom permission LibraryPermission "exc.reporter" to prohibit illegitimate callers from setting the default exception handler. This can be achieved by subclassing BasicPermission which allows binary style permissions (either allow or disallow). By default one cannot define permissions with actions using BasicPermission but the actions can be implemented in the subclass if required. BasicPermission is abstract even though it contains no abstract methods; it defines all the methods it extends from the Permission class. The custom defined subclass of BasicPermission class has to define two constructors in order to call the most appropriate (single or double argument) superclass constructor (the superclass lacks a default constructor). The two-argument constructor also accepts an action even though a basic permission does not use it. This is required for constructing permission objects from the policy file.

This compliant solution uses a security manager to check whether the caller has the requisite permission to set the handler. The code confronts the user with a SecurityException if the check fails. The custom permission class LibraryPermission is also defined with the two required constructors.

class LoadLibrary {
  private void loadLibrary() {
    AccessController.doPrivileged(new PrivilegedAction() {
      public Object run() {
        // privileged code
        System.loadLibrary("awt");
      
        SecurityManager sm = System.getSecurityManager();
        if(sm != null) {
          sm.checkPermission(new LibraryPermission("exc.reporter"));
        }

        // perform some sensitive operation like setting the default exception handler
        MyExceptionReporter.setExceptionReporter(reporter); 
        return null; 
      }
    });		  
  }
}

class LibraryPermission extends BasicPermission {
  public LibraryPermission(String permName) {
    super(permName);
  }

  // Even though the actions parameter is ignored, this constructor has to be defined
  public LibraryPermission(String permName, String actions) {
    super(permName, actions);
  }
}

Assuming that the above sources live in the c:\package directory on a Windows based system, the policy file needs to grant two permissions, LibraryPermission "exc.reporter" and the RuntimePermission "loadlibrary.awt".

grant codeBase "file:c:\\package" {  // For *nix, file:${user.home}/package/ 
  permission LibraryPermission "exc.reporter";
  permission java.lang.RuntimePermission "loadLibrary.awt"; 
};

Risk Assessment

Running Java code without defining custom permissions where default ones are inapplicable can leave an application open to privilege escalation vulnerabilities.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]] Class SecurityManager
[[Oaks 01]] Chapter 5: The Access Controller, "Permissions"
[[Policy 02]]
[[Sun 06]] Permission Descriptions and Risks

SEC10-J. Do not allow the unauthorized construction of sensitive classes      00. Security (SEC)      00. Security (SEC)