Section 15.10. Java Network Security Restrictions

[Page 752 (continued)] 15.10. Java Network Security Restrictions One of the most attractive features of Java is the extensive effort to make it a secure language. This is especially important for a language that makes it so easy to implement networking applications. After all, nobody wants to download a Java applet that proceeds to erase the hard disk. Such an applet might be written by a cyber-terrorist deliberately aiming to cause severe damage, or it might be written by a cyber-doofus who inadvertently writes code that does severe damage. What are some of Java's techniques for guarding against deliberate or inadvertent insecure code? One level of security is Java's bytecode verification process, which the Java Virtual Machine performs on any "untrusted" code it receives. Java checks every class that it loads into memory to make sure it doesn't contain illegal or insecure code. Another line of defense is the so-called sandbox security model, which refers to the practice of restricting the kinds of things that certain programs can do. For example, the "sandbox" environment for Java applets restricts them from having any access whatsoever to the local file system. Code verification Limited privileges Another restriction imposed on applets limits their networking capabilities. For example, a Java applet cannot create a network connection to any computer except the one from which its code was downloaded. Also, a Java applet cannot listen for, or accept, connections on privileged portsthose numbered 1024 or lower. Together, these two restrictions severely limit the kinds of client/server programs that can be built as applets. Limited network access Java sets aside certain locations as repositories for trusted code. The Java class libraries are placed in such a location, as are the directories where your Java programs are stored. Any class loaded from some other directory is considered untrusted. By this definition, applets downloaded over the Internet would be considered untrusted code. In addition to the restrictions for applets, which apply to all untrusted code, Java defines a number of other limitations: Untrusted code cannot make use of certain system facilities, such as System.exit() and classes in the java.security package. Untrusted code cannot make use of certain AWT methods, such as methods that access the system clipboard. Another AWT restriction is that any window created by untrusted code must display a message informing the user that it is untrusted. You may have seen such messages on windows opened from applets. Untrusted code is limited in the kinds of threads it can create. Trusted code JDK 1.2 introduced security enhancements based on the concepts of "permission" and "policy." Code is assigned "permissions" based on the security policy currently in effect. Each permission specifies the type of access allowed for a particular resource (such as "read" and "write" access to a specified file or directory, or "connect" access to a given host and port). The policy that controls permissions can be initialized from an external configurable policy file. Unless a permission is explicitly granted to code, it cannot access the resource guarded by the permission. These new enhancements offer a more fine-grained and extensible approach to security for both applets and applications. [Page 753] As this brief overview illustrates, the Java Virtual Machine is designed with security as one of its primary issues. This does not guarantee 100 percent security, but it is a big improvement over some of the languages and systems that preceded Java. Moreover, security is an ongoing concern of the Java development process. Flaws in the existing security system are fixed very quickly. Advanced methods are constantly being developed and incorporated into the system. One such enhancement is the use of encryption to guarantee the integrity of classes transferred over the network.