The base Java Security sandbox is comprised of three major components: the byte code Verifier, the Class Loader, and the Security Manager. Each of these components must work properly in order for Java to perform in a secure fashion. The Security Manager depends on Class Loaders to correctly label code as trusted or untrusted. Class Loaders also shield the Security Manager from spoofing attacks by protecting local trusted classes making up the Java API. On the other hand, the class loader system is protected by the Security Manager, which ensures that an applet cannot create and use its own Class Loader. The Verifier protects both the Class Loaders and the Security Manager against language-based attacks meant to break the VM. All in all, the three parts intertwine to create a default sandbox. However, the three parts are not created or specified by a standards committee. Java applications, including Java-enabled Web browsers, are allowed to customize two of the fundamental portions of the security model to suit their needs (the Class Loader and the Security Manager). The security model is much more distributed than many computer security experts would like [Badger and Kohli, 1995]. In the end, a great deal of faith is placed in the ability of VM implementations to ensure that untrusted code remains properly contained. Bugs in the system will compromise the entire security model. In 1996, we complained that there was no formal, high-level security model in Java. Instead, the security policy is derived from a collection of low-level detail checking. This is difficult because without a formal model it is impossible to say what secure means. With no standardized model, each vendor is free to define the term secure. In addition, no particular implementation can be verified. A little progress towards a more formal description of the security model was made when Sun commissioned a report entitled Security Reference Model for JDK 1.0.2 [Erdos, et al, 1996]. This sort of work is what users of security-critical consumerware should demand. Unfortunately, the SRM is now seriously out of date. Once again, Internet-time-compressed development schedules have outstripped the need for rigorous security design and analysis. This is a common trend in consumer software, and one that is destined to flame out under the rigorous security demands of e-commerce. Programming language researchers have also done some work trying to prove the soundness of the Java language and the VM definition [Drossopoulou and Eisenbach, 1998; Stata and Abadi, 1998]. Although this work is still in preliminary stages, some interesting and suggestive results are available. The bottom line is that the definition of Java will probably turn out to be sound, once many more details have been filled in. The Java runtime system is large (upwards of 28,000 lines of code, not including the VM). This raises important security assurance questions. Generally speaking, programs as large and complex as that are extremely hard to verify. It is common knowledge that buggy software causes many security vulnerabilities [Garfinkel and Spafford, 1996]. There is no centralized authority ensuring that Java's security code is bug free. The Java security system has seen the benefit of external peer review (some solicited and some not). JavaSoft has put together a Security Advisory Board (including one of the authors) and now includes prominent security researchers among its staff. Outsiders have done their best to keep security claims honest, and a number of security researchers (including the authors of this book) are spending a fair amount of effort still trying to find its weaknesses. Later in the book, we discuss some of the problems researchers have found, and what Java vendors are doing to address them. Before we dig into that topic, we introduce the new security mechanisms found in Java 2 and discuss why the Java security model is a completely new beast.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
