SEC10-J. Call the superclass's getPermissions method when writing a custom class loader

When writing a custom class loader, sometimes it is desirable to override the getPermissions method. In most cases, it is recommended that the implementation 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.

Noncompliant Code Example

This noncompliant code example shows a snippet of a custom class loader that overrides the getPermissions method and thus avoids the use of the default (more restrictive) getPermissions method defined in the Policy class. Moreover, a class defined using this class loader will have permissions that are completely independent of those specified in the system-wide policy file and will 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, as the overridden getPermissions() method calls super.getPermissions(), the default system-wide security policy is also consulted apart from the custom policy.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = super.getPermissions(cs);
  pc.add(new RuntimePermission("exitVM"));
  return pc;
}

Risk Assessment

Failure to consult the default system policy while defining a custom classloader violates the tenets of defensive programming and may result in classes defined using unintended permissions.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]] Class ClassLoader
[[Oaks 01]]
[[Security 06]]

SEC09-J. Prefer using SSLSockets over Sockets for secure data exchange      01. Platform Security (SEC)      01. Platform Security (SEC)