...
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.
Code Block | ||
---|---|---|
| ||
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 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.
Code Block | ||
---|---|---|
| ||
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:
Code Block |
---|
java -Djava.security.manager=/path/to/manager ...
|
...
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 | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
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, the appropriate checks are omitted in several instances.
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
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.
Code Block | ||
---|---|---|
| ||
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.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ENV02SEC60-J JG | high | probable | low | P18 | L1 |
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
...