...
As an example, the security manager denies applets all but the most essential privileges. It is designed to protect inadvertent system modification, information leakage and user impersonation. For Java applications that run from the command line, the a default or custom security manager can be set using a special flag described a little later. Alternatively, it is possible to install a security manager programatically.
...
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 example that follows, a null
value has been is passed to the setSecurityManager
method that is responsible for establishing a current instance of SecurityManager
. Moreover, the checkPermission
method (or any of the other check*
methods) method has not been used.
Code Block | ||
---|---|---|
| ||
try { System.setSecurityManager(null); } catch (SecurityException se) { System.out.println("SecurityManager is already set!"); } |
Compliant Solution
The SecurityManager
class was abstract
prior to Java 2, forcing the code to subclass it and define custom implementations. 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. In this case, checkRead()
succeeds if the current protection domain's file permission name tallies with that of the file name argument for the read
action.
Code Block | ||
---|---|---|
| ||
try { System.setSecurityManager(new CustomSecurityManager("password here")); SecurityManager sm = System.getSecurityManager(); if(sm != null) { //check if file can be read sm.checkRead("/temp/tempFile"); } } catch (SecurityException se) { System.out.println("Not allowed"); } |
The method detailed in the preceding lines was more prevalent in JDK versions 1.x. Two methods, checkPermission(Permission perm)
and checkPermission(Permission perm, Object context)
were added in J2SE 1.2. The motivations for this change were manifold -
- The
checkPermission
methods eliminated the need for hardcoding names of the checks in the call. - They used only one copy of the complicated algorithms and code for examining the Java runtime by using a common
checkPermission
method. - Newer permissions for resources could be easily added by encapsulating them in a new
Permission
class.
Compliant Solution
An 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 SecurityManager()); SecurityManager sm = System.getSecurityManager(); if(sm != null) { //check if file can be read sm.checkRead("/temp/tempFile"); } } catch (SecurityException se) { System.out.println("Not allowed"); } |
Compliant Solution
The methods detailed in the preceding compliant solutions were more prevalent in JDK versions 1.x. Two methods, checkPermission(Permission perm)
and checkPermission(Permission perm, Object context)
were added in J2SE 1.2. The motivations for this change were manifold -
- The
checkPermission
methods eliminated the need for hardcoding names of the checks in the call. - They used only one copy of the complicated algorithms and code for examining the Java runtime by using a common
checkPermission
method. - Newer permissions for resources could be easily added by encapsulating them in a new
Permission
class.
The single argument checkPermission
method uses the context of the currently executing environment to perform the checks. If the context has the permission as defined in the local policy file, the check succeeds, otherwise a SecurityException
is thrown.
...
Code Block | ||
---|---|---|
| ||
// Take the snapshot of the required context AccessControlContext acc = AccessController.getContext(); // ... acc.checkPermission(perm); // Check permissions in another context |
Compliant Solution
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 whenever the security manager is not set programatically. The default security manager can be installed using the flags as follows:
...