SEC30-J. Always use a Security Manager

According to the SUN J2SE documentation http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html

"The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed. The application can allow or disallow the operation."

As an example, the security manager denies applets all but the most essential privileges. The security manager is designed to protect inadvertent system modification, information leakage and user impersonation. From Java 2 Platform onwards, SecurityManager is a non-abstract class. As a result there is no explicit requirement of overriding its methods. To use a security manager, the code must have the runtime permissions createSecurityManager (to instantiate SecurityManager and avoid certain information leakage) and setSecurityManager to install it.

Noncompliant Code Example

The worst form of non-compliance is not using the the security manager at all. Even when used, there can be cases where the appropriate checks are not installed. In the noncompliant code that follows, a null value has been passed to the setSecurityManager method that is responsible for establishing a current instance of SecurityManager. Moreover, the checkPermission (or any check*) method has not been used.

try {
      System.setSecurityManager(null);
} catch (SecurityException se) { System.out.println("SecurityManager is already set!"); }

Any Java program (bean, servlet or application) can instantiate a SecurityManager. However, for applications designed to run locally, an explicit flag must be set to enforce the SecurityManager policy. In the noncompliant example highlighted below, this flag has not been used which circumvents all SecurityManager checks.

java application

Compliant Solution

This compliant solution demonstrates how a custom SecurityManager class called CustomSecurityManager can be activated by invoking its constructor with a password. Various check methods defined within the class can then be invoked to perform access checks. Alternatively, to use the default security manager change the active instance to java.lang.SecurityManager.

try {
      System.setSecurityManager(new CustomSecurityManager("password here"));
      SecurityManager sm = System.getSecurityManager();
      if(sm != null) {  //check if file can be read
        FilePermission perm = new FilePermission("/temp/tempFile", "read");
        sm.checkPermission(perm);
      } 
} catch (SecurityException se) { System.out.println("SecurityManager is already set!"); }

For local applications, the security manager can be installed using the flags as shown below. Note that the setSecurityManager method must be replaced by getSecurityManager in this case since the manager has already been installed using the command line flag.

java -Djava.security.manager -Djava.security.policy=policyURL LocalJavaApp

By default, the SecurityManager checkPermission method(s) forward all calls to the java.security.Accesscontroller.checkPermission. Sometimes it is required to perform checks against a different context than the currently executing threads' context. This can be done using the checkPermission(Permission perm, Object context) method which takes an extra argument (like AccessControlContext) as the context of the desired thread.

The document [[Policy 02]] discusses writing policy files in depth.

Risk Assessment

Running Java code without a Security Manager being set means that there is no security at all.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[API 06]] Class SecurityManager
[[Policy 02]]
[[Pistoia 04]] Section 7.4, The Security Manager
[[Gong 03]] Section 6.1, Security Manager