A Brief Introduction To Java Security
Nov 22, 1998
Department of Computer Science and Engineering
Helsinki University of Technology
The concerns for Java
security is bound with the power of Java. With Java Applet we
can download executable content from open network which brings both exciting
advantage and dangerous risk to us. The original Java security model is called
sandbox model, which creates an restricted working environment for untrusted code
obtained from the open network. To create such a sandbox we need cooperation from
Java language itself, run time class library, and web browser.
Since its birth in the early
70s as a twelve-node network callled the ARPANET, the Internet
has exponentially exploded into a world-wide network. It gained so much rapid expansion
not because of the network itself but because of the so-called World Wide Web technology.
Before 1992 when the World
Wide Web was introduced, the internet was almost exclusively
text-based and maily used by computer scientists and researchers. They used it to transfer
files to one another, and to keep in touch via e-mail. There is not much attractions to the public
here as you can see the Internet is associated with serious research work.
Then in 1992, Tim Berners-Lee,
a British researcher at the CERN physics facility in Europe,
introduced hypertext markup language (HTML) and Web browsing to the Internet. From then
on the Internet became colorful, lively, and more attractive than ever before. From the usr's
point of view the Internet is like a huge database from which they can get various kinds of
information (pure data). Also the ease of use of web browser makes seaching through the
Internet an feeling of "surfing".
Java makes it a step further.
Using Java with World Wide Web provides not only pure data
to users but also executable content as well. Users can download a Java Applet through the
Internet and make it run on his own computer. Since you have some code which written by
someone else other yourself executing on your computer, security issues are a fundamental
concern from the very beginning.
Because Java is a fully featured
programming language, and Java applications can read and
write files on locat computer, communicate with various devices, connect to sockets, and so
on, the Java security issues disscussed in this essay concerns only Java Applet.
2. Java Security Architecture
2.1 the Sandbox Model
The original security model
(in JDK1.0) provided by the Java platform is called Sandbox
Model, which creates a restricted working environment for untrusted code obtained from the
open network . With this model, all of the code is classified into two category: trusted
and untrusted. The trusted code, local code in JDK 1.0 and in JDK1.1 including signed
applets as well, have a full access to to valuable system resources (such as file systems)
while untrusted code can access only the limited resources provided inside the "sandbox",
as illustrated below.
Fig 2.1 JDK 1.0 Security Model 
In JDK 1.2 a new protection
architecture is introduced on the base of a new concept of
protection domain. Protection domains generally fall into two distinct categories: system
domain and application domain, and valuable resources like file system could be accessible
only via system domain. The Java application environment maintains a mapping from
code (classes and instances) to their protection domains and then to their permissions, as
illustrated by the figure below. 
Fig 2.2 Mapping from class to domain to permissions 
As we can see, from the Sandbox
Model to Protection Domain concept, the idea does not
change much. Only the mechanism, i.e., how to construct the sandbox, changed to be able
to handle the more complicated situation. No matter how much the concepts changed the
Java security system depends on the following parts: the Java language itself, the run time
class libraries, and the security manager of the browser .
2.2 Safety related characteristics of Java
2.2.1 Type Safety
One advantage of Java over
C/C++ is that it's born to be type-safed. This is the most essential
element of Java security. To understand why type safty matters, consider the following example.
applet defines a class called Alam, which defines an operation
that sets the first field to true. The Java run time library defines another class called Applet
with the first field fileAccessAllowed determining whether or not the applet is allowed access
to files on the hard disk. Suppose a program tried to apply the turnOn operation to an Applet
object. If the operation was allowed to go ahead, it would do what turnOn was supposed to do.
If we could cast the object from Applet class to Alam, then we can call turnOn operation on the
object, which actually is in the Applet class, setting the first field to true, thus allows the applet
to access the hard disk. The applet would then be allowed (incorrectly) to delete files. 
2.2.2 The Byte Code Verifier
The Byte Code Verifier is
called the first defense line of Java security model. It verifies the
code received from open network before the code is run. Only after code passing verification
can the class loader load the class and then the interpreter run the code.
The Verifier checks byte code at a number of different levels. The simplest test makes sure that
the format of a code fragment is correct. On a less basic level, a built-in theorem prover is
applied to each code fragment. The theorem prover helps to make sure that byte code does not
forge pointers, violate access restrictions, or access objects using incorrect type information.
The verification process, in concert with the security features built into the language and checked
by the compiler, helps to establish a base set of security guarantees. 
Only the Verifier work correctly is not engough in the context of Java security. The Java run time
system must be correctly implemented as well. Bugs in the run time system will make byte code
verification useless. It is especially critical to verify any third-party Java environment to ensure
that it properly implements the Java run time. Without a guarantee of bug-free run time, Java
security falls into pieces. 
2.2.3 The Applet Class Loader
The Applet Class Loader is
called the second defense line of Java security model, after the byte
code verifier. It determines when and how an applet can add classes to a running Java
environment . There is two important points regarding the applet class loader.
Firstly, under normal operation,
applets are forbidden to install a new Class Loader. Otherwise
an applet would be free to define its own name space and this allows an attack applet to breach
security . Secondly, when one class tries to reference another class, the Applet Class Loader
always follows a particular order of search, which firstly is the local name space (where built-in
classes live), then the name space of the class who is making the reference. Because of this order,
it prevents imported classes from pretending to be built-in classes, hence prevents such things as
applets redefining file I/O operations to gain unrestricted access to the file system .
2.2.4 The Java Security Manager
The Java Security Manager
is called the third defense line of Java security model. After codes
are verified by the Byte Code Verifier and classes are loaded by the Applet Class Loader, the
burden to guarantee the system security goes to the shoulder of the Java Security manager.
The security Manager is a
single module that performs run time checks on dangerous methods.
Code in the Java library consults the Security Manager whenever a potentially dangerous
operation is attempted. The Security Manager is given a chance to veto the operation by
generating a Security Exception. It has the following duties:
2.3 Different Classes of Security
Class libraries play an important role in the power of Java. Without
the class library included
in JDK and those from a third vender, you have to do everythign from scratch which is incredible.
However, the policy of how to deal with these library (e.g. where to put them in the local file
system) affects your system security directly.
Built-in classes, including JDK classes and those that have been proved
to be trustful, are
allowed to bypass the verification stage by being put in the classpath directory. Making a
change to the classpath, or placing a new class in one of these sub-directories is tantamount
to making a fundamental change in your security policy .
So think twice before isntalling any unkown origin classes as built-in
classes by putting them
in the classpath directory. To do so is like launching a timer bomb for yourself and nobody
knows when it explodes.
2.4 Browser-specific Security Rules
As a matter of fact, it's browser's responsibility to download Java
applets, run it and monitor
its behaviour. So two of the fundamental pieces of the Java security model, the Class Loader
and the Security Manager, are defined by the browser vender through subclassing .
The most popular browsers, Netscape Navigator and Microsoft Inter Explorer,
both enforce a
strict policy on Java applet. The rules are as follows:
There is toggle switch in both browsers which is used to enable (or
disable) Java Applet. Just
turn it off if you want an absolute safety.
The above introduction is mainly based on the research work of Gary
McGraw and Edward
Felten from Stanford University, which is for JDK 1.0 only. Now JDK 1.2 introduced a new
security archtecture which increased the security fairly much. But as I mentioned before, the
basic idea does not change. The changes exist in the mechanism (i.e. how to implement the
security policy) so that it could handle more complicated situations. For detailed information
please go to reference .
 Gary McGraw & Edward Felten, Java Security, Willey Computer
Publishing, New York,
1996, 192p [referred 22.11.1998].
 Li Gong, Java Security Architecture, <http://java.sun.com/products/jdk/1.2/docs/guide/
security/spec/security-spec.doc.html>, last modified: 02.10.1998 [referred 22.11.1998].