ENV31-J. Never grant AllPermission to untrusted code

The java.security.AllPermission class grants all possible permissions to the caller. This facility was included for routine testing purposes to make it less cumbersome to deal with a multitude of permissions or for use when the code is completely trusted. It should never be granted to untrusted code.

Noncompliant Code Example

This noncompliant example grants AllPermission to the klib library. The permission itself is specified in the security policy file used by the security manager. Alternatively, a permission object can be obtained in the code by subclassing the Permission class (or any subclass such as BasicPermission) in the java.security package. AllPermission can be granted to a ProtectionDomain using such an object. This is again a bad practice.

/* grant the klib library AllPermission */ 
grant codebase "file:${klib.home}/j2se/home/klib.jar" { 
  permission java.security.AllPermission; 
}; 

Compliant Solution

This compliant solution shows a policy file that can be used to enforce fine-grained permissions.

grant codeBase "file:${klib.home}/j2se/home/klib.jar", signedBy "Admin" {
    permission java.io.FilePermission "/tmp/*", "read";
    permission java.io.SocketPermission "*", "connect";
};

To check whether the caller has the requisite permissions, use the following check within the code:

//security manager code
perm = new java.io.FilePermission("/tmp/JavaFile","read");
//other code

Always assign appropriate permissions to code. When more control is required over the granularity of permissions, define custom permissions. (SEC08-J. Define custom security permissions for fine grained security)

Noncompliant Code Example

This noncompliant example shows an overridden getPermissions() method, defined in a custom class loader. It grants java.security.AllPermission to any class that it loads. This example also violates SEC10-J. Call the superclass's getPermissions method when writing a custom class loader.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = new Permissions();
  pc.add(new java.security.AllPermission());   // permission to create a class loader
  // other permissions
  return pc;
}

Compliant Solution

This compliant solution does not grant the java.security.AllPermission to any class it loads.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = super.getPermissions(cs);
  // other permissions
  return pc;
}

Exceptions

SEC31-EX1: It may be necessary to grant AllPermission to trusted library code so that callbacks will work. For example, it is a common practice to grant AllPermission to the optional Java system code packages:

// Standard extensions get all permissions by default
grant codeBase "file:${{java.ext.dirs}}/*" {
	permission java.security.AllPermission;
};

Risk Assessment

Granting AllPermission to untrusted code allows it to perform arbitrary operations.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[API 06]] Class AllPermission
[[Gong 03]]
[[Security 06]] Security Architecture

ENV30-J. Create a secure sandbox using a Security Manager      01. Platform Security (SEC)      ENV32-J. Do not grant ReflectPermission with target suppressAccessChecks