When a custom class loader must override the getPermissions()
method, the implementation must consult the default system policy by explicitly invoking the superclass's getPermissions()
method before assigning arbitrary permissions to the code source. The getPermissions()
method is actually defined by SecureClassLoader
, which extends ClassLoader
. ClassLoader
is abstract and must not be extended directly.
Noncompliant Code Example
This noncompliant code example shows a fragment of a custom class loader that extends the class URLClassLoader
. It overrides the getPermissions()
method and does not call the superclass's more restrictive getPermissions()
method. Consequently, a class defined using this custom class loader has permissions that are completely independent of those specified in the system-wide policy file; in effect, the class's permissions override them.
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = new Permissions(); pc.add(new RuntimePermission("exitVM")); // allow exit from the VM anytime return pc; }
Compliant Solution
In this compliant solution, the getPermissions()
method calls super.getPermissions()
. Consequently, the default system-wide security policy is applied, in addition to the custom policy.
protected PermissionCollection getPermissions(CodeSource cs) { PermissionCollection pc = super.getPermissions(cs); pc.add(new RuntimePermission("exitVM")); // allow exit from the VM anytime return pc; }
Risk Assessment
Failure to consult the default system policy while defining a custom classloader violates the tenets of defensive programming and can result in classes defined with unintended permissions.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC11-J |
high |
probable |
low |
P18 |
L1 |
Automated Detection
This can be addressed with a heuristic checker in the style of FindBugs. As with all heuristic checks, achieving a low false-positive rate is essential.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b6f37b0d-6003-4ba4-aa46-0d30785a6101"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. Bibliography#API 06]] |
[Class ClassLoader |
http://java.sun.com/javase/6/docs/api/java/lang/ClassLoader.html] |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="994958d2-e759-4953-9d08-bcbc3facb3dc"><ac:plain-text-body><![CDATA[ |
[[Oaks 2001 |
AA. Bibliography#Oaks 01]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c19c06c5-bc65-4eef-86b3-88c2aba07b96"><ac:plain-text-body><![CDATA[ |
[[Security 2006 |
AA. Bibliography#Security 06]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
SEC06-J. Do not base security checks on untrusted sources 14. Platform Security (SEC) SEC18-J. Define wrappers around native methods