BUY IT!
Securing Java

Previous Page
Previous Page
The Base Java Security Model:
The Original Applet Sandbox
Next Page
Next Page

Java is designed so that programs can be dynamically loaded over the network and run locally. This very powerful paradigm promises to change the face of computing as we know it. A browser that can interpret Java byte code (such as Netscape Navigator or Internet Explorer) can download and locally execute applets that are embedded in a Web page. This activity of downloading and executing is completely automatic, requires no user approval, and sometimes occurs without the user even knowing. Remember, by simply pointing your browser at a Web page containing an applet, you start Java. Any applet started in this fashion is not required to advertise its presence. More and more Java applets appear on the Web every day. Applets are becoming ubiquitous. This means that surfing the Web with a Java-enabled browser is a more risky activity than surfing the Web in the days before Java.

It is extremely unlikely that all users of Java-enabled browsers will consider the security implications of surfing a site before each Web page access. If the mobile code paradigm is going to work, security concerns should be addressed in the language of the content itself. That way, users will not need to worry too much about security. Java's designers took this task to heart. One of their fundamental concerns was making the use of Java transparent, automatic, and above all, safe. As a result, Java was developed with key security issues in mind.

It is clear that the Java development environment attempts to address the security problems introduced by the idea of dynamically downloading and running external, untrusted code. To what extent Java succeeds in this task is a subject of debate. Security concerns have always been one of the major technical stumbling blocks to achieving safe mobile code. Java took these concerns seriously and made a good effort to protect Web users. In this chapter, we present the original (or base) Java security model and discuss how it mitigates some of the risks that applets introduce.

The original Java security model presented in this chapter implements a sandbox that imposes strict controls on what certain kinds of Java programs can and cannot do. To the extent that the sandbox works, it allows a user to run untrusted code safely. As we discussed in Chapter 1, "Mobile Code and Security: Why Java Security Is Important," an alternative approach to handling mobile code is to run only code that is trusted. ActiveX controls, for example, are omnipotent and should be run only when you completely trust the entity (person or corporation) that signed the control. It is clear that future mobile code systems will involve both a sandbox model and a trust model based on code signing. In fact, the two will likely be so intertwined that they cannot be easily teased apart. This is already happening in Java.

There are many ways to impose a sandbox model on executable content-Java presents just one. Since the Java sandbox model has been widely distributed to millions of users with their Web browsers, it is safe to say that the Java sandbox is today's most widely used sandbox model. Until recently, it was correct to assume that a Java sandbox placed particular constraints on Java applets. JDK 1.1 changed all that; and as we pointed out in Chapter 1, the notion of a sandbox is becoming ever more complex.

With the introduction of JDK 1.1, Java's sandbox model underwent a state transition from a required model applied equally to all Java applets to a malleable system that could be expanded and personalized on an applet-by-applet basis. The addition of code signing to Java complicates things immensely. As it now stands, the Java sandbox we detail in this chapter has been reduced to a default. Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," discusses how things work when this default sandbox policy is not used.


Chapter Two Sections
  1. Potential Threats
  2. What Untrusted Java Code Can't Do
  3. What Untrusted Java Code Can Do
  4. The Java Language and Security
  5. The Three Parts of the Default Sandbox
  6. The Verifier
  7. The Class Loader Architecture
  8. The Security Manager
  9. Different Classes of Security
  10. Type Safety
  11. Browser-Specific Security Rules
  12. The Fundamental Tradeoff
  13. Is There Really a Java Security Policy?

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.