Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: general edit

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 (security policy file)

This noncompliant example grants AllPermission to the klib library.

Code Block
bgColor#FFcccc

// 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. 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.

Code Block
bgColor#FFcccc

// 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.

...

To check whether the caller has the requisite permissions, standard Java APIs use code such as:

Code Block
bgColor#ccccff
//security 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 (PermissionCollection)

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.

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

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

Compliant Solution

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

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

...

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 (extension libraries):

Code Block
bgColor#ccccff
// Standard extensions extend the core platform and are getgranted all permissions by default
grant codeBase "file:${{java.ext.dirs}}/*" {
  permission java.security.AllPermission;
};

...