Page History

The default {{SecurityManager}} checks whether the caller of a particular method has sufficient permissions to proceed with an action. An action is a level of access, for instance, the actions for {{java.io.FilePermission}} are "read", "write", "execute", and "delete" \[[Sun 06|AA. Java References#Sun 06]\]. The Permission Descriptions and Risks guide \[[Permissions 08|AA. Java References#Permissions 08]\] enumerates the default permissions and the risks associated with granting these permissions to Java code. 

Sometimes, stronger restrictions than those provided by the default security manager are necessary, and then custom . Custom permissions prove to be more suitable for privilege separation in such cases. Failure to provide custom permissions in the absence of the when no corresponding default permissions exist, can lead to privilege escalation vulnerabilities wherein untrusted callers can execute restricted operations or actions.

Noncompliant Code Example

This noncompliant code example contains a privileged block that is used to perform two sensitive operations, loading a library and setting the default exception handler. FortunatelyWhen used, when the default security manager is used, it does not permit the loading of the library unless the RuntimePermission loadLibrary.awt is granted in the policy file. Quite deplorablyHowever, the programmer security manager does not automatically guard a caller from performing the second sensitive operation of setting the default exception handler. This is because the permission for this operation is not non-default and consequently, unavailable. This security weakness can be exploited, for example, by programming and installing a an exception handler that reveals information that a legit handler would keep securefilter out.

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; 
      }
    });		  
  }
}

...

This compliant solution defines a custom permission ExceptionReporterPermission with target 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, permissions cannot be defined with to support actions using BasicPermission but the actions can be freely implemented in the subclass if required. BasicPermission is abstract even though it contains no abstract methods; it defines all the methods that it extends from the Permission class. The custom defined subclass of the BasicPermission class has to define two constructors to call the most appropriate (one- or two-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.

The compliant solution then uses a security manager to check whether the caller has the requisite permission to set the handler. The code issues throws a SecurityException if the check fails. The custom permission class ExceptionReporterPermission is also defined with the two required constructors.

...