Controlling Bytecode Verification Comparisons with Previous Releases

present only because the bytecode verifier could not run in certain limited memory configurations. However, although these options to the virtual machine are well−documented, they are not implemented on all platforms and they have not survived in Java 2. One way to ensure that application code is run through the bytecode verifier in 1.1 is to use the secure launcher from Appendix D.

3.4 Summary

Because the notion of security in Java is pervasive, its implementation is equally pervasive. In this chapter, weve explored the security mechanisms that are built into the Java language itself. Essentially, at this level the security mechanisms are concerned with establishing a set of rules for the Java language that creates an environment where an objects view of memory is well−known and well−defined so that a developer can ensure that items in memory cannot be accidentally or intentionally read, corrupted, or otherwise misused. We also took a brief look at Javas bytecode verifier, including why it is necessary and why you should turn it on, even for Java applications. Its important to keep in mind that the purpose of these security constraints is to protect the users machine from a malicious piece of code and not to protect a piece of code from a malicious user. Java does not and could not prevent a user from acting on memory from outside the browser, with possibly harmful results. Chapter 3. Java Language Security

Chapter 4. The Security Manager

In the next three chapters, were 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. • Well 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

4.1 Overview of the Security Manager

When most people think of Java security, they think of the protections afforded to a Java program −− and, more particularly, only by default to a Java applet −− by Javas security manager. There are other important