Page History

...

From Java 2 SE Platform onward, SecurityManager is a nonabstract class. As a result, there is no explicit requirement of overriding its methods. To create and use a security manager programmatically, the code must have the runtime permissions createSecurityManager (to instantiate SecurityManager) and setSecurityManager (to install it). These permissions are checked only if a security manager is already installed. This is useful for situations in which a global-default security manager is in place, such as on a virtual host, and individual hosts need to must be denied the requisite permissions for overriding the default security manager with a custom one.

...

This noncompliant code example fails to install the security manager from the command line. Consequently, the program runs with all permissions enabled; that is, there is no security manager to restrict prevent any nefarious actions the program might perform.

...

try {
  System.setSecurityManager(new SecurityManager());
} catch (SecurityException se) {
  // Cannot set security manager, log to fileappropriately
}

Compliant Solution (Custom Security Manager)

...

try {
  System.setSecurityManager(new CustomSecurityManager("password here"));
} catch (SecurityException se) {
  // Cannot set security manager, log to fileappropriately
}

After this code executes, APIs that perform security checks use the custom security manager. As noted earlier, custom security managers should be installed only when the default security manager lacks the required functionality.

Applicability

Java security heavily fundamentally depends on the existence of a security manager. In its absence, sensitive actions can execute and break the sandbox security offered by Java.

...