...
As an example, 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, malicious JSP code and 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.
...
Wiki Markup |
---|
Regarding the implementation and use of custom security managers as opposed to default ones, the Java Security Architecture Specification \[[SecuritySpec 08|AA. Java References#SecuritySpec 08]\] aptly paints the picturestates: |
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 byAccessController
whenever appropriate.
Many of the Java SE APIs use 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. Note that the documentation of some APIs, for example the java.io.FileReader
class, may not contain information about the SecurityException
because it is a subclass of RuntimeException
; it is not mandatory to document runtime exceptions. Installing a security manager from the command line or programatically helps create a default sandbox that denies such permissions if the security policy file in effect does not permit the actions.
Noncompliant Code Example (command line installation)
This noncompliant code example does not install the security manager from the command line (assuming that the security manager is not set programatically).
Code Block | ||
---|---|---|
| ||
java LocalJavaApp |
Compliant Solution (default policy file)
Any Java program (bean, servlet or application) can instantiate a SecurityManager
programatically in the absence of a default, global security manager that does not permit this operation. Applications designed to run locally can use a default global security manager by explicitly setting a flag on the command line while invoking the application.
The command line option is usually desired preferred when applications must be prohibited from installing custom security managers programatically and must obey 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 allowable actions.
...
Even a custom security manager can be made the default and enforced globally from the command line by specifying its absolute path location, immediately after an equal-to sign that must appear after the -Djava.security.manager
flag. If it is known in advance that the user prefers using the default global security manager installed from the command line, invoking the setSecurityManager()
method can be forgone in code. In fact, using this method will throw a SecurityException
if the current security policy enforced by the global security manager does not permit replacements (by not granting the RuntimePermission("setSecurityManager")
).
The default security policy file java.policy
grants a few permissions (reading system properties, binding to unprivileged ports and so forth) and can be found in the ~/java.home/lib/security
directory on UNIX-like systems and its equivalent on Microsoft Windows systems. There is also a user specific policy file in the user's home directory. The union of both these policy files defines the permissions given to a program. Refer to the java.security
file to set which policy files should be used. If either of these is deleted, by default no permissions are granted to the implementing code.
Compliant Solution (custom policy file)
If the default policy file needs to be bypassed in lieu of a custom policy file, the double equals (==
) idiom should be used instead of the single equals =
.
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.
...
Wiki Markup |
---|
Notably, 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}}. Its default value is {{true}}. The document "Default Policy Implementation and Policy File Syntax" \[[Policy 02|AA. Java References#Policy 02]\] discusses writing policy files in depth. |
Noncompliant Code Example
...
(programmatic installation)
When Even when the SecurityManager
API is used to install the security manager instead of the command line, there can be instances where the appropriate checks are not installed.
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 (assuming that the security manager is not installed from the command line).
Code Block | ||
---|---|---|
| ||
try { System.setSecurityManager(null); } catch (SecurityException se) { // cannot set security manager, log to file } |
Compliant Solution (default security manager)
This compliant solution demonstrates how a custom SecurityManager
class called CustomSecurityManager
can be instantiated by invoking its constructor with a password and set as instantiates and sets the default security manager. The APIs that have security checks built into them will use the custom security manager subsequently.
Code Block | ||
---|---|---|
| ||
try { System.setSecurityManager(new CustomSecurityManagerSecurityManager("password here")); } 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, and set as the default security managerAn alternative is to use the default security manager instead of a custom one, as shown below. To do this, change the active instance to java.lang.SecurityManager
(invoke setSecurityManager()
with the argument new SecurityManager()
).
Code Block | ||
---|---|---|
| ||
try { System.setSecurityManager(new SecurityManagerCustomSecurityManager("password here")); } catch (SecurityException se) { // cannot set security manager, log to file } |
The APIs that have security checks built into them will use the custom security manager subsequently. As noted earlier, custom security managers should only be rolled out when the default security manager does not provide the required functionality.
Risk Assessment
Running Java code without a Security Manager being set means that there is no restrictive sandbox and arbitrary code may get executedexecute.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ENV02- J | high | probable | low | P18 | L1 |
...