According to the SUN J2SE documentation http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html
"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."
As an example, the security manager denies applets all but the most essential privileges. The security manager is designed to protect inadvertent system modification, information leakage and user impersonation. From Java 2 Platform onwards, SecurityManager
is a non-abstract class. As a result there is no explicit requirement of overriding its methods. To use a security manager, the code must have the runtime permissions createSecurityManager
(to instantiate SecurityManager
and avoid certain information leakage) and setSecurityManager
to install it.
Noncompliant Code Example
The worst form of non-compliance is not using the the security manager at all. Even when used, there can be cases where the appropriate checks are not installed. In the noncompliant code that follows, a null
value has been passed to the setSecurityManager
method that is responsible for establishing a current instance of SecurityManager
. Moreover, the checkPermission
(or any check*
) method has not been used.
try { System.setSecurityManager(null); } catch (SecurityException se) { System.out.println("SecurityManager is already set!"); }
Any Java program (bean, servlet or application) can instantiate a SecurityManager
. However, for applications designed to run locally, an explicit flag must be set to enforce the SecurityManager
policy. In the noncompliant example highlighted below, this flag has not been used which circumvents all SecurityManager
checks.
java application
Compliant Solution
This compliant solution demonstrates how a custom SecurityManager
class called CustomSecurityManager
can be activated by invoking its constructor with a password. Various check methods defined within the class can then be invoked to perform access checks. Alternatively, to use the default security manager change the active instance to java.lang.SecurityManager
.
try { System.setSecurityManager(new CustomSecurityManager("password here")); SecurityManager sm = System.getSecurityManager(); if(sm != null) { //check if file can be read FilePermission perm = new FilePermission("/temp/tempFile", "read"); sm.checkPermission(perm); } } catch (SecurityException se) { System.out.println("SecurityManager is already set!"); }
For local applications, the security manager can be installed using the flags as shown below. Note that the setSecurityManager
method must be replaced by getSecurityManager
in this case since the manager has already been installed using the command line flag.
java -Djava.security.manager -Djava.security.policy=policyURL LocalJavaApp
By default, the SecurityManager
checkPermission
method(s) forward all calls to the java.security.Accesscontroller.checkPermission
. Sometimes it is required to perform checks against a different context than the currently executing threads' context. This can be done using the checkPermission(Permission perm, Object context)
method which takes an extra argument (like AccessControlContext)
as the context of the desired thread.
The document [[Policy 02]] discusses writing policy files in depth.
Risk Assessment
Running Java code without a Security Manager being set means that there is no security at all.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC30-J |
high |
probable |
low |
P18 |
L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[API 06]] Class SecurityManager
[[Policy 02]]
[[Pistoia 04]] Section 7.4, The Security Manager
[[Gong 03]] Section 6.1, Security Manager
SEC07-J. Minimize accessibility 00. Security (SEC) SEC31-J. Never grant AllPermission to untrusted code