Page History

Sensitive operations must be protected by security manager checks.

Noncompliant Code Example

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 might contain sensitive information. However, the method is public and non-final, which leaves it susceptible to malicious callers.

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

  public void removeEntry(Object key) {
    ht.remove(key);
  }
}

Compliant Solution

This compliant solution installs a security check to protect entries from being maliciously removed from the Hashtable instance. A SecurityException is thrown if the caller does not possess the java.security.SecurityPermission removeKeyPermission.

...

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

Noncompliant Code Example (check*())

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 code must not use the check*() methods because the default implementations of the Java libraries already use these methods to protect sensitive operations.

SecurityManager sm = System.getSecurityManager();


if (sm != null) {  // check whether file may be read
  sm.checkRead("/local/schema.dtd");
}

Compliant Solution (checkPermission())

J2SE 1.2 added two methods — checkPermission(Permission perm) and checkPermission(Permission perm, Object context) — to the SecurityManager class. The motivations for this change included

...

SecurityManager sm = System.getSecurityManager();

if (sm != null) {  //check if file can be read
  DTDPermission perm = new DTDPermission("/local/",  "readDTD");
  sm.checkPermission(perm);
}

Compliant Solution (Multiple Threads)

Occasionally, the security check code exists in one context (such as a worker thread) while the check has to 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 the intersection of the permissions of the two contexts.

...

// Take the snapshot of the required context, store in acc and pass it to another context
AccessControlContext acc = AccessController.getContext();

// Accept acc in another context and invoke checkPermission() on it
acc.checkPermission(perm);

Risk Assessment

Failing to enforce security checks in code that performs sensitive operations can lead to malicious tampering of sensitive data.

Automated Detection

Identifying sensitive operations requires assistance from the programmer; fully-automated identification of sensitive operations is beyond the current state of the art.

Given knowledge of which operations are sensitive, as well as which security checks must be enforced for those operations, an automated tool could reasonably enforce the invariant that the sensitive operations are invoked only from contexts where the security checks have been performed.

Bibliography

...

SEC02-J. Remove superfluous code from privileged blocks      14. Platform Security (SEC)      Image RemovedSEC04-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes