The static method java.security.AccessController.doPrivileged affirms that the invoking method assumes responsibility for enforcing its own privileges and that the access permissions of its callers should be ignored. For example, an application may could have permissions to operate on a sensitive file, however, a caller of the application may be allowed to operate with only the basic permissions. Invoking doPrivileged() in this context allows the application operating with basic permissions to use the sensitive file, for instance, when a user password change request requires an unprivileged application to use a more privileged application to set the new password.
...
In general, when any method containing the doPrivileged block exposes a field (such as a reference) beyond its own boundary, it becomes trivial for untrusted callers to exploit the program. Both of the following compliant solutions (below) avoid exposing any reference to the privileged data.
...
This compliant solution logs exceptions to a privileged log file. This choice is appropriate when data attached to the exception could potentially leak privileged information (e.g. for example, the path to a privileged file).
...
The previous compliant solution logs the exception instead of revealing sensitive information. (See guideline [EXC06-J. Do not allow exceptions to transmit sensitive information for more information.) When none of the possible exceptions reveals sensitive information, we can use an equivalent mechanism that allows exceptions to be wrapped, thus providing better diagnostic information for the caller. For example, an applet that lacks read-access to system files that contain fonts can accomplish the task from a privileged block without revealing any sensitive information. When non-sensitive exceptions provide more information, the client is better able to recognize the symptoms of a read failure.
...
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Related Guidelines
SCG 2007 Guideline 6-1. Safely invoke java.security.AccessController.doPrivileged
MITRE CWE: CWE-266 "Incorrect Privilege Assignment"
MITRE CWE: CWE-272 "Least Privilege Violation"
Bibliography
| Wiki Markup |
|---|
\[[API 2006|AA. Bibliography#API 06]\] [method doPrivileged()|http://java.sun.com/javase/6/docs/api/java/security/AccessController.html#doPrivileged(java.security.PrivilegedAction)]
\[[Gong 2003|AA. Bibliography#Gong 03]\] Sections 6.4, AccessController and 9.5 Privileged Code
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 6-1 Safely invoke java.security.AccessController.doPrivileged
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 266|http://cwe.mitre.org/data/definitions/266.html] "Incorrect Privilege Assignment", [CWE ID 272|http://cwe.mitre.org/data/definitions/272.html] "Least Privilege Violation" |
...
SEC01-J. Minimize the accessibility of classes and their members 02. Platform Security (SEC) SEC03-J. Do not allow tainted variables in doPrivileged blocks