Page History

...

• Defining custom policies: It is sometimes desired to subclass the security manager to define multilevel, coarse or fine grained security policies with system wide application.

The Java Security Architecture Specification \[[SecuritySpec 08|AA. Java References#SecuritySpec 08]\] aptly paints the picture:

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 by AccessController whenever appropriate.

Noncompliant Code Example

...

try {
      System.setSecurityManager(null);
} catch (SecurityException se) { System.out.println("SecurityManager is already set!"); }

...

Various check methods defined within the class can then be invoked to perform access checks. Alternatively, to use the default security manager instead of a custom one, change the active instance to java.lang.SecurityManager (invoke setSecurityManager() with the argument new SecurityManager()). 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.

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

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()).

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"); }

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.

...

java -Djava.security.manager -Djava.security.policy=policyURL LocalJavaApp

In this case, note that the setSecurityManager() method can be forgone and substituted with just the getSecurityManager() method as the manager has already been installed using the command line flag.

The default policy file java.policy grants a few permissions (reading system properties, binding to unprivileged ports and so 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.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.

...

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.  

...