Java has outgrown the original restrictive sandbox. The anticipated future of mobile code security, a complex mix of sandboxing and code signing, is now upon us with Java 2. In essence, the three parts of the sandbox explained in the previous chapter implement a language-based security enforcer. This enforcement model has been hybridized and expanded to include fine-grained notions of trust and permission built on digital signatures. That means major changes to Java security. This chapter centers on those changes. Chapter 1, "Mobile Code and Security: Why Java Security Is Important," briefly introduced the notion of code signing and mobile code policy through the discussion of ActiveX. The ActiveX trust model is suited only to run completely trusted code. At the core of that kind of trust model is a black-and-white decision either to trust the code or not. Such a decision can be influenced by determining who vouches for the code. Digital signatures are used for the vouching. Java's approach to trust is also based on digital signatures. However, instead of allowing only black-and-white trust decisions � la ActiveX, Java 2 allows fine-grained access control decisions to be made. With the introduction of code signing in 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. Java 2 further complicates the picture with the addition of access control. When combined with access control, code signing allows applets to step outside the security sandbox gradually. In fact, the entire meaning of sandbox becomes a bit vague. As an example of how Java code signing might work, an applet designed for use in an Intranet setting could be allowed to read and write to a particular company database as long as it was signed by the system administrator. Such a relaxation of the security model is important for developers who have complained about Java's restrictive sandbox. Writing code that works within the tight restrictions of the sandbox is a pain, and the original sandbox is very restrictive. The addition of code signing to Java complicates things. As it now stands, the Java sandbox has been reduced to a default. The whole game has changed. Tracing the history of this change as we do in this chapter can lend some important perspective. Before we dig into the complex issues of code signing and trust models, it does us good to review what it is we're trying to achieve in the first place. After all, the point of all this highfalutin' architecture is not to make the world's most complicated system. The real objective is securing mobile code. After we remind ourselves of the main goal of the new security model, we are ready to trace its evolution. We will begin by explaining the enhancements added to Java with the release of JDK 1.1, and go on to discuss the Java 2 model in detail.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
