Versions Compared

Key

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

...

"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 SecurityManager security manager denies applets all but the most essential privileges. The SecurityManager 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. Thus 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.

Non-Compliant Code Example

The worst form of non-compliance is not using the the SecurityManager security manager at all. Even when used, there can be cases where the appropriate check methods checks are not calledinstalled. In the non-compliant 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.

...

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 non-compliant example highlighted below, this flag has not been used which circumvents all SecurityManager checks.

Code Block
bgColor#FFcccc
java application

...

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.

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

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

...