The New Java Security Model
The Need for Java Security
From its inception, Java has shown that it was designed for the net. Java brought about, for the first time on a large scale, the concept of dynamic loading of code from a source outside the system. Though this is very powerful, and adds several features to the system using it, it is also a grave security threat. There are several risks associated with loading and running remote code. The remote code could steal memory, or CPU time; it could throw in a virus; it could read files on a local system and transmit them to another machine, etc. It is clear, then, that unlike other programming languages and systems, security mechanisms must be an integral part of Java.
Moreover, Java is not just for applets any more. Developers now use Java to build stand-alone, enterprise-class applications to enable disparate clients, such as workstations, PCs or Java-based network computers to access legacy databases and share applications across the network.
Java was designed to offer the following basic security measures:
• Language design features, such as legal type conversions only, no pointer arithmetic and bounds checking on arrays, provide strong memory protection.
• A sandbox mechanism controls what a Java program is permitted to do.
• Encryption and digital signatures are used by code owners to attach their certificate to Java classes. In this way, the end user can ascertain who the owner of the code is and whether the class file was altered after having been signed by the owner’s certificate.
Java security builds upon three fundamental aspects of the Java Run time Environment (JRE):
1. Class loader
The class loader determines how and when Java programs can load codes, and ensures that system-level components within the run-time environment are not replaced.
2. Class file verifier
The class file verifier ensures proper formatting of downloaded code. It verifies that the bytecode does not violate the type safety restrictions of the Java Virtual Machine (JVM), that internal stacks cannot over/underflow, and that the bytecode instructions will have correctly typed parameters.
3. Security manager
The security manager performs run-time access controls on attempts to perform file I/O, network I/O, create a new class loader, manipulate threads and thread groups, start processes on the underlying operating system, terminate the JVM, load non-Java libraries (native code) into the JVM, perform certain types of windowing system operations and load certain types of classes into the
JVM. For example, the Java applet sandbox , which severely constrains downloaded, untrusted applets to a limited set of functions that are considered to be relatively safe, is a function of the security manager.
Java security functionalities, even if built and designed in the language itself, have been changing their features over time, and their evolution has been dependent on the major Java language releases that have been developed until now: JDK 1.0, JDK 1.1 and Java 2 SDK, Standard Edition, V1.2.
