The Java Security Model

Now that you know what restrictions the Java security system enforces, you'd probably like to know how it does this. The answer is shown in Figure 18.2, which shows the four layers in the Java security model. Each layer provides a unique barrier to the construction and execution of applets with evil intent.

  

Now let's examine each of the layers in Figure in detail.

he Compiler and the Java Language

One of the first barriers to rogue applets is the design of the Java language. Because Java doesn't have pointers and is strongly type checked-so much so that you can't cast an integer to an object reference-many of the traditional security holes found in C and C++ are plugged. For example, because there are no pointers, Java applets can't invade the memory space of another program. These architectural features are actually beneficial in that they eliminate the most common coding errors that cause problems in C++. In fact, the lack of pointers and the automatic garbage collection will probably lead to a factor of two or more reduction in software development costs for any application that doesn't require low-level control of the machine-such as a device driver-because of the time saved tracking down pointer-related errors in the code.

The compiler plays a role in this by enforcing the rules and prohibiting various types of potentially dangerous casts.

The ByteCode Verifier

This is the heart of the Java security scheme. If someone figures out how to get past this, real trouble can arise. The basic job of this layer is to verify every program before it's run. This protects you against someone hand-coding a class file that violates the Java security rules or developing a compiler that doesn't enforce the Java security rules.

The ByteCode verifier is a very powerful guard which first verifies that the file is a properly structured Java class file. The next step is complex and involves proving certain theorems about the class. The process guarantees the following about the applet:

• It doesn't cause stack over- or underflows.
• Operators' arguments are of the proper type: An integer isn't being used with an operator that requires an object reference for example.
• Objects are only accessed according to the approved rules; for example, this refers to accessing private and protected methods.
• No casts that violate Java security rules are attempted.

This approach has a significant side benefit of making the interpreter run faster, because it doesn't have to check for any of these problems.

The ClassLoader

After a class has been verified, it can be loaded into the Java system. In order to prevent applets from replacing security-related classes and thereby breaking the security system, Java divides the namespace into several levels. Currently there are three levels: the local file system-most protected; the local network-middle protection; and the Internet-least protected. The class loader won't replace a class in a more protected level with a class from a less protected level. The really key classes, such as those that control I/O, are in the local level so no applet that is coming from another machine can override and replace them.

Additionally, the class loader prevents classes in one layer from accessing any non-public methods in classes in other layers. In a similar fashion, when multiple applets are loaded, they're placed in separate namespaces so that they can't interact unless they're designed to do so.

The SecurityManager

This is actually an abstract class that is designed to allow you to tailor the security policies that a browser or application will enforce. Applets can't modify the SecurityManager, but applications can extend it and define their own security policies. Your security policies, as determined by your SecurityManager, determine what types of dangerous operations an applet can perform. For example, the Netscape SecurityManager prohibits all file reading/writing, but other browser SecurityManagers could allow different levels of file access depending upon the source of the applet.

These four levels working together provide a nearly airtight defense against malicious applets. There are still some security problems (researchers have been finding a new problem every few months), but they are fairly difficult to exploit. In fact, the real problem is that, because the security system limits file and network I/O (a key reason for the wonderfulness of networks and computers), there are too many powerful and useful applications that can't be written.