BUY IT!
Securing Java

Previous Page
Previous Page
The Base Java Security Model: The Original Applet Sandbox
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13

Section 9 -- Different Classes of Security

Next Page
Next Page

In the early days of Java, life was simple, security policy was black and white, and external code was summarily untrusted. Since then, life has become more complex, security policy is now made to order, and code runs the gamut from trusted to untrusted (encompassing every state in between). Figure 1.6 in Chapter 1 illustrates the difference in trust models. It is easiest to get a grasp on the notion of trust assigned to Java classes by harkening back to ancient Java history circa 1996.


JDK 1.0

As Figure 2.8 shows, in JDK 1.0 there are only three possible paths that byte code can take through the Java security model. The path taken is determined by the origin of the byte code. Built-in byte code from the JDK 1.0 distribution (off the local disk) is allowed to bypass the verification stage. This means that built-in classes are assumed to be both correct and well behaved. All other JDK 1.0 byte code classes must pass through the strict security checks.

Fig 2.8

Figure 2.8 There are three possible paths that Java byte code may follow through the JDK 1.0.2/JDK 1.1 security models.

The path chosen depends on where the byte code originates and (in the case of JDK 1.1) what signatures the code carries. External byte code (loaded across the network) that is not signed by a trusted party (1) must be Verified and is subject to the Class Loader and the Security Manager. Locally developed byte code (2) is subject to the same checks (unless it is placed on the CLASSPATH). Byte code from the JDK distribution (including other packages placed on the CLASSPATH) and any class that is signed by a trusted party (3) does not pass through the Verifier and may be subject to further optional security checks.


Built-In Classes: The Privileged Few
The JDK includes a class library that makes Java as powerful as it is. Since this code is part of Java itself, it is considered trustworthy. The fact that built-in Java classes bypass security measures has many implications. The system makes sense when you consider that this code is part of the Virtual Machine itself. If the VM is loaded before the Verifier, there is no choice but to consider the built-in Java classes trustworthy.

It is not just JDK classes that can bypass security. In JDK 1.0, any class stored on the local file system and made part of the local approved set of classes will be considered a built-in class. Such classes are, however, only subject to automatic loading if they are placed in one of the subdirectories in the CLASSPATH. Making a change to the CLASSPATH, or placing a new class in one of these subdirectories is tantamount to making a fundamental change in your security policy. A good example of classes given built-in status is the set of class files included with Netscape Navigator: classes.zip.

Under JDK 1.0, it is essential that you never install classes of unknown origin as built-in classes by putting them in the CLASSPATH. Since the security checks are bypassed for this kind of byte code, granting such classes built-in status is very dangerous. Install only vendor-supplied classes as built-in classes.

The file system loader (aka the Primordial Class Loader) shown in Figure 2.8 sets up the namespace for built-in classes. This namespace is special. The local namespace is exclusively reserved for built-in classes. This helps protect built-in classes (including essential classes like the Security Manager) from being spoofed by outside classes.

Built-in classes may or may not be subjected to the Security Manager, depending on the policy of the site. Vendor-supplied classes often require unhindered access to system resources. Classes like the ClassLoader must be trusted in order to bootstrap the system.


Non-Built-In Classes: The Unwashed Masses
In JDK 1.0, all classes not considered built-in are subject to more strict security checks. Paths (1) and (2) of Figure 2.8 both apply to non-built-in classes. Classes in path (1) include all applets loaded from the network. Classes in path (2) include all applets loaded locally, but not specified in the CLASSPATH. It is not possible to stress heavily enough how important it is to consider carefully which classes you grant built-in status. If you install a Java class in your CLASSPATH it will no longer be subject to security checks. Only completely trusted code should be given this privilege.

In summary, under JDK 1.0, built-in classes and classes loaded from the CLASSPATH are trusted classes. Classes loaded from a URL (either a file: type or an http: type) are untrusted classes.


JDK 1.1

Under JDK 1.1 the same system applies as was the case in JDK 1.0. However, a class loaded from the network can become trusted if it is digitally signed by a party whom the user has decided to trust. The idea is to allow code signed by a trusted party to attain the same level of privilege as is usually afforded to built-in code. This is a decision not to be taken lightly. Security ramifications are just as critical as those raised when adding classes to the CLASSPATH. Note that the way JDK 1.1 is used in practice, the resulting trust model is still black and white. Code is still either completely trusted, or it's not trusted at all.


Java 2

With Java 2, things get even more complicated. Built-in classes are still completely trusted, but external, digitally signed classes can become partially trusted at the whim of the user. By adding partial trust and access control to the VM, Java 2 opens the door for complex, fine-grained security policies that grant privileges according to identity. See Figure 2.9.

Fig 2.9

Figure 2.9 In Java 2, all code is distinctly identified by where it comes from and what signatures it carries.

Byte code may make calls to potentially dangerous functionality. When such calls are made, the AccessController (new to Java 2) consults policy and uses stack inspection to decide whether to allow or disallow a call. The distinction between applets and applications no longer applies.

Chapter 3 is devoted to understanding the subtleties of this new approach to Java security.

Previous Page
Previous Page


Search Help
Next Page
Next Page


Menu Map -- Text links below

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help

Copyright ©1999 Gary McGraw and Edward Felten.
All rights reserved.
Published by John Wiley & Sons, Inc.