Malicious Mobile Code

Java Security

As was briefly mentioned before, Java was built from the ground up to limit what mischief a malicious Java applet could do. Java’s creators had to release a language that would allow component downloading with the toughest security of any language while giving users a portable, flexible, and powerful feature set. This was no easy task. Security is always a cost/benefit compromise. Make the security so tight that no one can break it and you probably don’t have much of a program. Give a program useful flexibility and you increase the risk of malicious use.

Java Security -- Classic Model

Java’s original security model, released in JDK 1.0, is a multitiered protected environment called the sandbox. The sandbox severely limits what remotely accessed applets can do, while allowing locally launched and trusted applets full system access. Java’s sandbox (see Figure 10-2) is maintained by cooperative JVM components known as the Byte Code Verifier , the Class Loader , and the Security Manager .

Figure 10-2. Java applet pathway and security

Even before applet byte code reaches the JVM’s sandbox, Java goes out of its way to protect the user. The Java language is designed to prevent misbehaving memory pointers and provides range-checking on strings and arrays. In most languages it is all too easy to write buggy code because memory management is the responsibility of the programmer, ...