Security - Java Coding Guidelines - page 71

This guideline addresses the problem of excess privileges. See Guideline 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.
Click here to view code image
class LoadLibrary {
private void loadLibrary() {
AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
// Privileged code
System.loadLibrary("myLib.so");
// Perform some sensitive operation like
// setting the default exception handler
MyExceptionReporter.setExceptionReporter(reporter);
return null;
}
});
}
}
When used, the default security manager forbids the loading of the library unless the
RuntimePermission loadLibrary.myLib is granted in the policy file. However, the se-
curitymanagerdoesnotautomaticallyguardacallerfromperformingthesecondsensitive
operationofsettingthedefaultexceptionhandlerbecausethepermissionforthisoperation
isnondefault and,consequently,unavailable. This security weakness can beexploited, 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 the target exc.reporter to prohibit illegitimate callers from setting the default ex-
ception handler. This can be achieved by subclassing BasicPermission , which allows
binary -stylepermissions(eitherallowordisallow).Thecompliantsolutionthenusesase-
curity 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.