Introducing the Security Manager

Each Java application can have its own security manager object that acts as a full-time security guard. The SecurityManager class in the java.lang package is an abstract class that provides the programming interface and partial implementation for all Java security managers.
By default an application does not have a security manager. That is, the Java runtime system does not automatically create a security manager for every Java application. So by default an application allows all operations that are subject to security restrictions.
To change this default lenient behavior, an application must create and install its own security manager. You will learn how to create a security manager in Writing a Security Manager, and how to install it in Installing Your Security Manager.

Note: The existing browsers and applet viewers do create their own security manager when starting up. Thus an applet is subject to whatever access restrictions are imposed on it by the security manager for the particular application in which the applet is running.

You can get the current security manager for an application using the System class's getSecurityManager() method:
SecurityManager appsm = System.getSecurityManager();
Note that getSecurityManager() returns null if there is no current security manager for the application so you should check to make sure that you have a valid object before calling any of its methods.
Once you have the security manager, you can request permission to allow or disallow certain operations. Indeed many of the classes in the Java packages do just this. For example, the System.exit() method, which terminates the Java interpreter, uses the security manager's checkExit() method to approve the exit operation:
SecurityManager security = System.getSecurityManager();
if (security != null) {
    security.checkExit(status);
}
. . .
// code continues here if checkedExit() returns
If the security manager approves the exit operation, the checkExit() returns normally. If the security manager disallows the operation, the checkExit() method throws a SecurityException. In this manner, the security manager is allows or disallows a potentially threatening operation before it can be completed.
The SecurityManager class defines many other methods used to verify other kinds of operations. For example, SecurityManager's checkAccess() method verifies thread accesses, and checkPropertyAccess() verifies access to the specified property. Each operation or group of operations has its own checkXXX() method.
In addition, the set of checkXXX() methods represent the set of operations in the Java package classes and the Java runtime that are already subject to the protection of the security manager. So, typically, your code will not have to invoke any of SecurityManager's checkXXX() methods--the Java package classes and the Java runtime already do this for you at a low enough level that any operation represented by a checkXXX() method is already protected. However, when writing your own security manager, you may have to override SecurityManager's checkXXX() methods to tighten or modify the security policy for specific operations, or you may have to add a few of your own to put other kinds of operations under the scrutiny of the security manager. Deciding What SecurityManager Methods to Override explains which operation or group of operations each checkXXX() method in the SecurityManager class is designed to protect.

Accessing System Resources