SEI CERT Oracle Coding Standard for Java

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

According to the SUN J2SE documentation http://java.sun.com/j2se/1.4.2/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 SecurityManager denies applets all but the most essential privileges. The SecurityManager 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.

Non-Compliant Code Example

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

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 non-compliant 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.

http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html discusses writing policy files in good depth.

References

Default Policy Implementation and Policy File Syntax http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html]
Enterprise Java Security: Building Secure J2EE Applications, 7.4 The Security Manager
Inside Java 2 Platform Security

  • No labels