Page History

Certain combinations of permissions can produce significant capability increases and should not be granted. Other permissions should only be granted only to special code.

AllPermission

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

TheGranting {{ReflectPermission}} permission when granted on the target {{suppressAccessChecks}} suppresses all standard Java language access checks when the permitted class attempts to operate on public, defaultpackage-private, protected, or private members of another class. Consequently, the permitted class can obtain permissions to examine any field or invoke any method belonging to an arbitrary class \[[Reflect 2006|AA. Bibliography#Reflect 06]\]. As a Consequentlyresult, the {{ReflectPErmissionReflectPermission}} permision must never be granted with target {{suppressAccessChecks}}.

...

Warning: Extreme caution should be taken before granting this permission to code, for it provides the ability to access fields and invoke methods in a class. This includes not only public, but protected and private fields and methods as well.

RuntimePermission, createClassLoader

The permission java.lang.RuntimePermission permission applied to target createClassLoader grants permission to code so that it can create a ClassLoader object. This 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 system-wide systemwide security policy file.

The document Permissions 2008, in Section RuntimePermission, says_Permissions in the Java™ SE 6 Development Kit (JDK)_ Permissions 2008 states:

This is an extremely dangerous permission to grant. Malicious applications that can instantiate their own class loaders could then load their own rogue classes into the system. These newly loaded classes could be placed into any protection domain by the class loader, thereby automatically granting the classes the permissions for that domain.

...

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 (BasicPermission, for example). 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";
};

...

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

...

Compliant Solution

This compliant solution omits granting the 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);
  // other permissions
  return pc;
}

Exceptions

ENV03-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):

...

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

Bibliography

...