ENV03-J. Never grant AllPermission to untrusted code

The permission java.security.AllPermission implies all other permissions, thus granting java.security.AllPermission indeed grants all possible permissions to code. This facility was included to reduce the burden of managing a multitude of permissions during routine testing, as well as to use when a body of code is completely trusted. Code is typically granted AllPermission via the security policy file; it is also possible to programmatically associate AllPermission with a ProtectionDomain. This permission is dangerous in production environments; never grant AllPermission to untrusted code.

Noncompliant Code Example (Security Policy File)

This noncompliant example grants AllPermission to the klib library.

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

The permission itself is specified in the security policy file used by the security manager. Program code can obtain a permission object by subclassing the java.security.Permission class or any of its subclasses (for examle, BasicPermission). The code can use the resulting object to grant AllPermission to a ProtectionDomain. This is bad practice.

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, standard Java APIs use code, such as the following:

// Security manager code
perm = new java.io.FilePermission("/tmp/JavaFile", "read");
AccessController.checkPermission(perm);
// ...

Always assign appropriate permissions to code. Define custom permissions when the granularity of the standard permissions is insufficient. See rule SEC10-J. Define custom security permissions for fine grained security for more information.

Noncompliant Code Example (PermissionCollection)

This noncompliant example shows an overridden getPermissions() method that is defined in a custom class loader. The class loader erroneously grants java.security.AllPermission to any class that it loads.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = new Permissions();
  pc.add(new java.security.AllPermission());   
  // other permissions
  return pc;
}

This example also violates rule SEC11-J. Call the superclass's getPermissions method when writing a custom class loader.

Compliant Solution

This compliant solution fails to grant the java.security.AllPermission to any class that it loads.

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = super.getPermissions(cs);
  // add fine-grained permissions
  return pc;
}

Exceptions

ENV03-EX1: It may be necessary to grant AllPermission to trusted library code so that callbacks work as expected. For example, it is common practice to grant AllPermission to the optional Java packages (extension libraries):

// Standard extensions extend the core platform and are granted 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 privileged operations.

Automated Detection

Static detection of potential uses of AllPermission is a trivial search. Automated determination of the correctness of such uses is not feasible.

Related Vulnerabilities

Bibliography

ENV02-J. Create a secure sandbox using a Security Manager      15. Runtime Environment (ENV)      ENV04-J. Do not grant ReflectPermission with target suppressAccessChecks