SEC58-J. Create a secure sandbox using a Security Manager

According to the Java API [[API 2006]], class SecurityManager documentation

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.

The applet security manager denies applets all but the most essential privileges. It is designed to protect inadvertent system modification, information leakage and user impersonation. The use of security managers is not limited to client side protection. Webservers, such as Tomcat and Websphere, use this facility to isolate trojan servlets and malicious JSP code, as well as to protect sensitive system resources from inadvertent access.

For Java applications that run from the command line, a default or custom security manager can be set using a special flag. Alternatively, it is possible to install a security manager programatically. Installing a security manager this way helps create a default sandbox that allows or denies sensitive actions based on the security policy in effect.

From Java 2 SE Platform onwards, SecurityManager is a non-abstract class. As a result, there is no explicit requirement of overriding its methods. To create and use a security manager programatically, the code must have the runtime permissions createSecurityManager (to instantiate SecurityManager) and setSecurityManager to install it. These permissions are checked only if a security manager is already installed. This is useful for situations where there is a global-default security manager in place, such as on a virtual host, and individual hosts need to be denied the requisite permissions for overriding the default security manager with a custom one.

The security manager is closely tied to the AccessController class. The former is used as a hub for access control whereas the latter is the actual implementer of the access control algorithm. The security manager supports

• Providing backward compatibility: Legacy code often contains custom implementations of the security manager class because it was originally abstract.
• Defining custom policies: Subclassing the security manager permits definition of custom security policies (for example, multilevel, coarse, or fine grain).

Regarding the implementation and use of custom security managers, as opposed to default ones, the Java Security Architecture Specification [[SecuritySpec 2008]] states

We encourage the use of AccessController in application code, while customization of a security manager (via subclassing) should be the last resort and should be done with extreme care. Moreover, a customized security manager, such as one that always checks the time of the day before invoking standard security checks, could and should utilize the algorithm provided by AccessController whenever appropriate.

Many of the Java SE APIs perform security manager checks by default before performing sensitive operations. For example, the constructor of class java.io.FileInputStream throws a SecurityException if the caller does not have the permission to read a file. Because SecurityException is a subclass of RuntimeException, the declarations of some API methods (e.g. those of the java.io.FileReader class) may lack a throws clause that lists the SecurityException. Avoid depending on the presence or absence of security manager checks that are not specified in the API method's documentation.

Noncompliant Code Example (Command Line Installation)

This noncompliant code example fails to install the security manager from the command line.

java LocalJavaApp

Compliant Solution (Default Policy File)

Any Java program can attempt to install a SecurityManager programmatically; a default global security manager may forbid this operation. Applications designed to run locally can specify a default global security manager by use of a flag on the command line at invocation.

The command line option is preferred when applications must be prohibited from installing custom security managers programmatically and, thus, are required to abide by the default global security policy under all circumstances. This compliant solution installs the default security manager using the appropriate command line flags. The security policy file grants permissions to the application for its intended actions.

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

The command line flag can specify a custom security manager whose policies are enforced globally. Use the -Djava.security.manager flag, as follows:

java -Djava.security.manager=/path/to/manager ...

Invocation of the setSecurityManager() method may be omitted in controlled environments where it is known that a default global security manager is always installed from the command line; this is not a typical case. In this case, attempts to invoke setSecurityManager() will throw a SecurityException if the current security policy enforced by the global security manager forbids replacements (by omitting the RuntimePermission("setSecurityManager")).

The default security policy file {{java.policy}}—found in the /path/to/java.home/lib/security directory on UNIX-like systems and its equivalent on Microsoft Windows systems—grants a few permissions (reading system properties, binding to unprivileged ports, and so forth). There may also be a user-specific policy file located in the user's home directory. The union of these policy files specifies the permissions granted to a program. The java.security file can specify which policy files are used. If either of the system-wide java.policy or java.security files is deleted, no permissions are granted to the executing Java program.

Compliant Solution (Custom Policy File)

Use double equals (==) instead of the single equals = when overriding the global Java security policy file with a custom policy file.

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

Compliant Solution (Additional Policy Files)

The appletviewer automatically installs a security manager with the standard policy file. To specify additional policy files, use the -J flag.

appletviewer -J-Djava.security.manager -Djava.security.policy==policyURL LocalJavaApp

Note that the policy file specified in the argument is ignored when the policy.allowSystemProperty property in the security properties file (java.security) is set to false; the default value of this property is true. The document "Default Policy Implementation and Policy File Syntax" [[Policy 2002]] discusses in depth the issues of and syntax for writing policy files.

Noncompliant Code Example (Programmatic Installation)

When the SecurityManager API is used instead of the command line to install the security manager, there are instances where the appropriate checks are omitted.

This noncompliant code example passes a null value to the setSecurityManager method that is responsible for setting the expected SecurityManager argument. As a result, no security manager is installed programmatically. In the case where the command line failed to install a security manager, this noncompliant code example would execute in the total absence of any security manager.

try {
  System.setSecurityManager(null);
} catch (SecurityException se) {
  // cannot set security manager, log to file
}

Compliant Solution (Default Security Manager)

This compliant solution instantiates and sets the default security manager.

try {
  System.setSecurityManager(new SecurityManager());
} catch (SecurityException se) {
  // cannot set security manager, log to file
}

Compliant Solution (Custom Security Manager)

This compliant solution demonstrates how a custom SecurityManager class called CustomSecurityManager can be instantiated by invoking its constructor with a password; this security manager is then installed as the security manager.

try {
  System.setSecurityManager(new CustomSecurityManager("password here"));
} catch (SecurityException se) {
  // cannot set security manager, log to file
}

After this code executes, APIs that perform security checks use the custom security manager. As noted earlier, custom security managers should be installed only when the default security manager lacks the required functionality.

Risk Assessment

All Java security depends on the existence of a SecurityManager. In the absence of a SecurityManager, arbitrary code can execute, which can include code provided by an attacker.

Automated Detection

Programmatic detection of the presence or absence of a SecurityManager at runtime is straightforward. Static analysis can address the presence or absence of code that would attempt to install a SecurityManager if the code were executed. Checking whether the SecurityManager is installed early enough, specifies the desired properties, or is guaranteed to be installed may be possible in some special cases, but is not feasible in full generality.

Related Vulnerabilities

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

Related Guidelines

MITRE CWE: CWE-358 "Improperly Implemented Security Check for Standard"

Bibliography

[[API 2006]] Class SecurityManager, Class AccessControlContext, Class AccessController
[[Gong 2003]] Section 6.1, Security Manager
[[Pistoia 2004]] Section 7.4, The Security Manager
[[Policy 2002]][[SecuritySpec 2008]] 6.2 SecurityManager versus AccessController

ENV01-J. Place all privileged code in a single package and seal the package      15. Runtime Environment (ENV)      ENV03-J. Never grant AllPermission to untrusted code