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... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
