A Brief Introduction To Java Security
 

                                          Nov 22, 1998
 
                                                                 Yue Wang
                                     Department of Computer Science and Engineering
                                                 Helsinki University of Technology
                                                           ywang2@cc.hut.fi
 
 

                                                               Abstract

        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.
 

        1. Introduction

        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 [2]. 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 [2]

        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. [2]

                           Fig 2.2 Mapping from class to domain to permissions [2]

        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 [1].

        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.

        A calendar-management applet defines a class called Alam, which defines an operation turnOn
        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. [1]
 

        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. [1]
 
        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. [1]
 

        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 [1]. 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 [1]. 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 [1].
 

        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:

• Preventing installation of new Class Loaders.
• Protecting threads and thread groups from each other.
• Controlling the creation of OS programs.
• Controlling access to OS processes.
• Controlling file system operations such as read and write.
• Controlling socket operations such as connect and accept.
• Controlling access to Java packages (or groups of classes). [1]

 
With the advent of digitally signed applet coming with JDK 1.1 and using encryption-based
authentication methods, the Security Manager could set up much more sophisticated rules for
trusted, partially-trusted, and untrusted applet, and thus will certainly improve the Java
Security model.
 

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 [1].

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 [1].

The most popular browsers, Netscape Navigator and Microsoft Inter Explorer, both enforce a
strict policy on Java applet. The rules are as follows:
 

• Applets cannot read or write files locally.
• Applets cannot open a network connection to any machine other than the applet's origin
        host.
• Applets can read only nine system properties. This allows an applet to access information
        such as the vendor who created the Java VM, the VM version number, the file separation
        character (either / or \), the character used to separate lines, and so on. Applets are not
        permitted to read any other system properties.
• If an applet is loaded using the file: URL, and it does not reside in a directory in classpath,
        it is loaded by the Applet Class Loader. [1]

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.
 

3. Conclusion

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 [1].
 
 

Reference

[1] Gary McGraw & Edward Felten,  Java Security, Willey Computer Publishing, New York,
      1996, 192p [referred 22.11.1998].
[2] 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].