Java Security, 2nd Edition

Chapter 4. The Security Manager

In the next three chapters, we’re going to discuss how the sandbox of a Java application is implemented. The implementation of the sandbox depends on three things:

• The security manager, which provides the mechanism that the Java API uses to see if security-related operations are allowed.

• The access controller, which provides the basis of the default implementation of the security manager.

• The class loader, which encapsulates information about security policies and classes.

We’ll start by examining the security manager. From the perspective of the Java API, there is a security manager that actually is in control of the security policy of an application. The purpose of the security manager is to determine whether particular operations should be permitted or denied. In truth, the purpose of the access controller is really the same: it decides whether access to a critical system resource should be permitted or denied. Hence, the access controller can do everything the security manager can do.

The reason there is both an access controller and a security manager is mainly historical: the access controller is only available in Java 2 and subsequent releases. Before the access controller existed, the security manager relied on its internal logic to determine the security policy that should be in effect, and changing the security policy required changing the security manager itself. Starting with Java 2, the security manager defers these decisions to the access controller. Since the security policy enforced by the access controller can be specified by using policy files, this allows a much more flexible mechanism for determining policies. The access controller also gives us a much simpler method of granting fine-grained, specific permissions to specific classes. That process was theoretically possibly with the security manager alone, but it was simply too hard to implement.

But the large body of pre-Java 2 programs dictates that the primary interface to system security -- that is, the security manager -- cannot change; otherwise, existing code that implements or depends on the security manager would become obsolete. Hence, the introduction of the access controller did not replace the security manager -- it supplemented the security manager. This relationship is illustrated in Figure 4-1. Typically, an operation proceeds through the program code into the Java API, through the security manager to the access controller, and finally into the operating system. In certain cases, however, the security manager may bypass the access controller. And native libraries are still outside the domain of either the security manager or the access controller (although the ability to load those libraries may be restricted).

Figure 4-1. Coordination of the security manager and the access controller