
...
Always assign appropriate permissions to code. Define custom permissions when the granularity of the standard permissions is insufficient.
Noncompliant Code Example (PermissionCollection
)
This noncompliant code example shows an overridden getPermissions()
method, defined in a custom class loader. It grants java.lang.ReflectPermission
with target suppressAccessChecks
to any class that it loads.
Code Block | ||
---|---|---|
| ||
protected PermissionCollection getPermissions(CodeSource cs) {
PermissionCollection pc = super.getPermissions(cs);
pc.add(new ReflectPermission("suppressAccessChecks")); // Permission to create a class loader
// Other permissions
return pc;
}
|
Compliant Solution
This compliant solution does not grant java.lang.ReflectPermission
with target suppressAccessChecks
to any class that it loads:
Code Block | ||
---|---|---|
| ||
protected PermissionCollection getPermissions(CodeSource cs) {
PermissionCollection pc = super.getPermissions(cs);
// Other permissions
return pc;
}
|
Exceptions
ENV03-J-EX0: It may be necessary to grant AllPermission
to trusted library code so that callbacks work as expected. For example, it is common practice, and acceptable, to grant AllPermission
to the optional Java packages (extension libraries):
Code Block | ||
---|---|---|
| ||
// Standard extensions extend the core platform and are granted all permissions by default
grant codeBase "TODO" {
permission java.security.AllPermission;
}; |
Risk Assessment
Granting AllPermission
to untrusted code allows it to perform privileged operations.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ENV03-J | High | Likely | Low | P27 | L1 |
Automated Detection
Static detection of potential uses of dangerous permissions is a trivial search. Automated determination of the correctness of such uses is not feasible.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar |
| JAVA.IO.PERM | Permissive File Mode (Java) |
Related Vulnerabilities
CVE-2007-5342 describes a vulnerability in Apache Tomcat 5.5.9 through 5.5.25 and 6.0.0 through 6.0.15. The security policy used in the JULI logging component failed to restrict certain permissions for web applications. An attacker could modify the log level, directory, or prefix attributes in the org.apache.juli.FileHandler
handler, permitting them to modify logging configuration options and overwrite arbitrary files.
Related Guidelines
Android Implementation Details
The java.security
package exists on Android for compatibility purposes only, and it should not be used. Android uses another permission mechanism for security purposes.
Bibliography
[API 2014] | Class |
Section 2.5, "Reflection" | |
Section " | |
...