Page History

...

This guideline addresses the problem of excess privileges. See 16. Avoid granting excess privileges for another approach to solving this problem.

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. 

...

When used, the default security manager forbids the loading of the library unless the RuntimePermission loadLibrary.awt is granted in the policy file. However, the security manager does not automatically guard a caller from performing the second sensitive operation of setting the default exception handler because the permission for this operation is nondefault and consequently unavailable. This security weakness can be exploited, for example, by programming and installing an exception handler that reveals information that a legitimate handler would filter out.

Compliant Solution

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). The compliant solution then uses a security manager to check whether the caller has the requisite permission to set the handler. The code throws a SecurityException if the check fails. The custom permission class ExceptionReporterPermission is also defined with the two required constructors.

...

By default, permissions cannot be defined to support actions using BasicPermission, but the actions can be freely implemented in the subclass ExceptionReporterPermission 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 behavior is required for constructing permission objects from the policy file. Note that the custom-defined subclass of the BasicPermission class is declared to be final in accordance with guideline VOID 15. OBJ56-JG. Either design classes for inheritance or declare them as final.

Applicability

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

Bibliography

...