Versions Compared

Key

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

...

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 default security manager can be set using a special flag described later. Alternatively, it is possible to install a security manager programatically.

From Java 2 SE Platform onwards, SecurityManager is a non-abstract class. As a result, there is no explicit requirement of overriding its methods. To create and use a security manager programatically, the code must have the runtime permissions createSecurityManager (to instantiate SecurityManager and avoid certain information leakage) and setSecurityManager to install it.

...

Code Block
bgColor#FFcccc
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 next, this flag has not been used which circumvents all SecurityManager checks.

Code Block
bgColor#FFcccc
java application

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.

...

Code Block
bgColor#ccccff
// 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 For local applications, the security manager can be installed using the flags as follows:

...

In this case, note that the setSecurityManager() method in code can be forgone and substituted with just the getSecurityManager() method as the manager has already been installed using the command line flag. A custom security manager can be installed by adding the path to the custom security manager after the flag.

The default policy file java.policy grants a few permissions (reading system properties, binding to unprivileged ports and so 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. Refer to the java.security file to set which policy files should be used. If either of these is deleted, by default no permissions are granted to the implementing code.

...