When writing a custom class loader , sometimes it is desirable needs to override the getPermissions() method. In most cases, it is recommended that the implementation should consult the default system policy before assigning arbitrary permissions to the code source. This can be automatically handled by explicitly invoking the superclass's getPermissions() method before assigning arbitrary permissions to the code source.
Noncompliant Code Example
This noncompliant code example shows a snippet 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. Note that URLClassLoader's getPermissions() method calls the Policy class's getPermissions() method which by default, uses the global system-wide policy file to enforce access control. Consequently, a class defined using the this custom class loader has permissions that are completely independent of those specified in the system-wide policy file and ; in effect, the class's permissions override them.
...
In this compliant solution, as the overridden getPermissions() method calls super.getPermissions(). Thus, the default system-wide security policy is also consulted in addition to the custom policy.
...
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
SEC11-J | high | probable | low | P18 | L1 |
Automated Detection
TODOThis 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 guideline on the CERT website.
...