Page History

...

This noncompliant code example instantiates a Hashtable and defines a removeEntry() method to allow the removal of its entries. This method is considered sensitive, perhaps because the hashtable hash table might contain sensitive information. However, the method is public and non-finalnonfinal, which leaves it susceptible to malicious callers.

...

class SensitiveHash {
  Hashtable<Integer,String> ht = new Hashtable<Integer,String>();

  void removeEntry(Object key) {
    check("removeKeyPermission");
    ht.remove(key);
  }

  private void check(String directive) {
    SecurityManager sm = System.getSecurityManager();
      if (sm != null) {
        sm.checkSecurityAccess(directive);
      }
  }
}

The SecurityManager.checkSecurityAccess() method determines whether the action controlled by the particular permission is allowed.

...

This noncompliant code example uses the SecurityManager.checkRead() method to check whether the file schema.dtd can be read from the file system. The check*() methods lack support for fine-grained access control. For example, the check*() methods are inadequate to enforce a policy permitting read access to all files with the dtd extension and forbidding read access to all other files. New Non-JDK code must not use the check*() methods because the default implementations of the Java libraries already use these methods to protect sensitive operations.

...

• eliminating the need to hard code names of checks in method names.
• encapsulating the complicated algorithms and code for examining the Java runtime in a single checkPermission() method.
• supporting introduction of additional permissions by subclassing the Permission class.

The single argument checkPermission() method uses the context of the currently executing thread environment to perform the checks. If the context has the permissions defined in the local policy file, the check succeeds; otherwise, a SecurityException is thrown.

...

Occasionally, the security check code exists in one context (such as a worker thread), while the check has to must be conducted on a different context, such as another thread. The two-argument checkPermission() method is used in this case. It accepts an AccessControlContext instance as the context argument. The effective permissions are those of the context argument only and are not computed as rather than the intersection of the permissions of the two contexts.

Both the single-and double-argument checkPermission() methods defer to the single-argument java.security.AccessController.checkPermission(Permission perm) method. When invoked directly, this method operates only on the current execution context and, as a result, does not supersede the security manager's two argument version.

A cleaner approach to making a security check from a different context is to take a snapshot of the execution context in which the check must be performed, using the java.security.AccessController.getContext() method that returns an AccessControlContext object. The AccessControlContext class itself defines a checkPermission() method that encapsulates a context , instead of accepting the current executing context as a parameter. This allows the check to be performed at a later time, as shown in the following example.

...

...