java.security.AccessController class is part of Java's security mechanism; it is responsible for enforcing the applicable security policy. This class's static
doPrivileged() method executes a code block with a relaxed security policy. The
doPrivileged() method stops permissions from being checked further down the call chain.
Consequently, any method that invokes
doPrivileged() must assume responsibility for enforcing its own security on the code block supplied to
doPrivileged(). Likewise, code in the
doPrivileged() method must not leak sensitive information or capabilities.
For example, suppose that a web application must maintain a sensitive password file for a web service and also must run untrusted code. The application could then enforce a security policy preventing the majority of its own code—as well as all untrusted code—from accessing the sensitive file. Because it must also provide mechanisms for adding and changing passwords, it can call the
doPrivileged() method to temporarily allow untrusted code to access the sensitive file. In this case, any privileged block must prevent all information about passwords from being accessible to untrusted code.
Noncompliant Code Example
In this noncompliant code example, the
doPrivileged() method is called from the
openPasswordFile() method. The
openPasswordFile() method is privileged and returns a
FileInputStream for the sensitive password file. Because the method is public, it could be invoked by an untrusted caller.
In general, when any method containing a privileged block exposes a field (such as an object reference) beyond its own boundary, it becomes trivial for untrusted callers to exploit the program. This compliant solution mitigates the vulnerability by declaring
openPasswordFile() to be private. Consequently, an untrusted caller can call
changePassword() but cannot directly invoke the
Compliant Solution (Hiding Exceptions)
The previous noncompliant code example and the previous compliant solution throw a
FileNotFoundException when the password file is missing. If the existence of the password file is itself considered sensitive information, this exception also must be prevented from leaking outside the trusted code.
This compliant solution suppresses the exception, leaving the array to contain a single null value to indicate that the file does not exist. It uses the simpler
PrivilegedAction class rather than
PrivilegedExceptionAction to prevent exceptions from propagating out of the
doPrivileged() block. The
Void return type is recommended for privileged actions that do not return any value.
Returning references to sensitive resources from within a
doPrivileged() block can break encapsulation and confinement and can leak capabilities. Any caller who can invoke the privileged code directly and obtain a reference to a sensitive resource or field can maliciously modify its elements.
Identifying sensitive information requires assistance from the programmer; fully automated identification of sensitive information is beyond the current state of the art.
Assuming user-provided tagging of sensitive information, escape analysis could be performed on the
doPrivileged() blocks to prove that nothing sensitive leaks out from them. Methods similar to those used in thread-role analysis could be used to identify the methods that must, or must not, be called from
Guideline 9-3 / ACCESS-3: Safely invoke
Android Implementation Details
java.security package exists on Android for compatibility purposes only, and it should not be used.
Section 6.4, "