Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 (for example, 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. Consequently, the program runs with all permissions enabled; that is, there is no security manager to prevent any nefarious actions the program might perform.

Code Block
bgColor#FFcccc
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 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 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.

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:

Code Block
bgColor#ccccff
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.

...

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, the appropriate checks are omitted in several instances.

...

Note that if a SecurityManager were already active when this code is invoked, it would probably prevent the system from removing it, causing this code to throw a SecurityException.

Compliant Solution (Default Security Manager)

This compliant solution instantiates and sets the default security manager:

Code Block
bgColor#ccccff
try {
  System.setSecurityManager(new SecurityManager());
} catch (SecurityException se) {
  // Cannot set security manager, log appropriately
}

Compliant Solution (Custom Security Manager)

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

...

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.

Applicability

Java security fundamentally depends on the existence of a security manager. In its absence, sensitive actions can execute and break the sandbox security offered by Java.

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, whether it specifies the desired properties, or whether it is guaranteed to be installed may be possible in some special cases but is not feasible in full generality.

Bibliography

[API 2011]Class SecurityManager
Class AccessControlContext
Class AccessController
[Gong 2003]§6.1, "Security Manager"
[Pistoia 2004]§7.4, "The Security Manager"
[Policy 2002]"Default Policy Implementation and Policy File Syntax"
[SecuritySpec 2008]§6.2, "SecurityManager versus AccessController"

...