Page History

...

The permission java.security.AllPermission 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 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.

ReflectPermission, suppressAccessChecks

...

The permission java.lang.RuntimePermission applied to target createClassLoader grants code the permission to create a ClassLoader object. This permission is extremely dangerous because malicious code can create its own custom class loader and load classes by assigning them arbitrary permissions. A custom class loader can define a class (or ProtectionDomain) with permissions that override any restrictions specified in the systemwide 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 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 (BasicPermission, for example). The code can use the resulting object to grant AllPermission to a ProtectionDomain.

...

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";
};

...

protected PermissionCollection getPermissions(CodeSource cs) {
  PermissionCollection pc = super.getPermissions(cs);
  pc.add(new ReflectPermission("suppressAccessChecks"));   // permissionPermission to create a class loader
  // otherOther permissions
  return pc;
}

Compliant Solution

This compliant solution does not grant java.lang.ReflectPermission with target suppressAccessChecks to any class that it loads.:

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

Exceptions

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

...

Risk Assessment

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

Automated Detection

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

Related Vulnerabilities

CVE-2007-5342 describes a vulnerability in Apache Tomcat 5.5.9 through 5.5.25 and 6.0.0 through 6.0.15. The security policy used in the JULI logging component failed to restrict certain permissions for web applications. An attacker could modify the log level, directory, or prefix attributes in the org.apache.juli.FileHandler handler, permitting them to modify logging configuration options and overwrite arbitrary files.

Related Guidelines

Android Implementation Details

The java.security package exists on Android for compatibility purposes only, and it should not be used. Android uses another permission mechanism for security purposes.

Bibliography

...