The permission java.security.AllPermission
implies all permissions and grants all possible permissions to code. This facility was included for routine testing purposes to make it less cumbersome to deal with a multitude of permissions and for use when the code is completely trusted. Code is typically granted AllPermission
using the security policy file but it is also possible to associate AllPermission
with a ProtectionDomain
, programatically. This permission is dangerous in production environments and must 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 java.security.Permission
class (or any subclass such as BasicPermission
). 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, standard Java APIs use code such as:
//security manager code perm = new java.io.FilePermission("/tmp/JavaFile","read"); AccessController.checkPermission(perm); //other code
Always assign appropriate permissions to code. When more control over the granularity of permissions is required, define custom permissions. (SEC10-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 SEC11-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()); // 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); // add fine-grained permissions return pc; }
Exceptions
EX1: It may be necessary to grant AllPermission
to trusted library code so that callbacks work as expected. For example, it is a common practice to grant AllPermission
to the optional Java packages:
// Standard extensions extend the core platform and 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 privileged operations.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
ENV31- J |
high |
likely |
low |
P27 |
L1 |
Automated Detection
TODO
Related Vulnerabilities
References
[[API 06]] Class AllPermission
[[Gong 03]]
[[Security 06]] Security Architecture
ENV02-J. Create a secure sandbox using a Security Manager 01. Runtime Environment (ENV) ENV04-J. Do not grant ReflectPermission with target suppressAccessChecks