Page History

According to the Java API Class SecurityManager documentation [API 20112013],

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 against inadvertent system modification, information leakage, and user impersonation. The use of security managers is not limited to client-side protection. Web servers, such as Tomcat and WebSphere, use this facility to isolate trojan servlets and malicious Java Server Pages (JSP) code as well as to protect sensitive system resources from inadvertent access.

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

From Java 2 SE Platform onward, SecurityManager is a nonabstract class. As a result, there is no explicit requirement of overriding to override its methods. To create and use a security manager programmatically, 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 in which a global- default security manager is in place, such as on a virtual host, and individual hosts must 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 provides the actual implementer implementation 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 security architecture specification [SecuritySpec 20082010] 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.

...

This noncompliant code example fails to install the any security manager from the command line. Consequently, the program runs with all permissions enabled; that is, there is no security manager to prevent any nefarious actions the program might perform.

...

Any Java program can attempt to install a SecurityManager programmatically; a default global , although the currently active 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.

...

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=my.security.CustomManager ...

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 If the current security policy enforced by the global current security manager forbids replacements (by omitting the RuntimePermission("setSecurityManager")), any attempt to invoke setSecurityManager() will throw a SecurityException.

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). Also, a A user-specific policy file may be 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 systemwide java.policy or java.security files is deleted, no permissions are granted to the executing Java program.

...

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

Compliant Solution (Additional Policy Files)

...

appletviewer -J-Djava.security.manager \
             -J-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 20022010] 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, the appropriate checks are omitted in several instancesA SecurityManager can also be activated using the static System.setSecurityManager() method. Only one SecurityManager may be active at a time. This method replaces the currently active SecurityManager with the SecurityManager provided in its argument or no SecurityManager if its argument is null.

This noncompliant code example passes a null value to the setSecurityManager method that is responsible for setting the expected SecurityManager argumentdeactivates any current SecurityManager but does not install another SecurityManager in its place. Consequently, subsequent code will run without any security manager monitoring accesswith all permissions enabled; there will be no restrictions on any nefarious action the program might perform.

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

...