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