What Untrusted Java Code Can't Do (Ch. 2, Sec. 2) [Securing Java]

The Base Java Security Model: The Original Applet Sandbox
CHAPTER SECTIONS: 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13

Section 2 -- What Untrusted Java Code Can't Do

Trusted Java applications do not have the same security implications as untrusted applications (including a majority of applets found on the Web). Thus, with a trusted application, it is possible to read and write files, communicate with devices, connect to sockets, and so on. But untrusted code is different. Clearly, untrusted code needs to be stopped from doing some of these things. Untrusted access to the more powerful features of Java must be properly restricted.

From the perspectives of both end users and system administrators, the most important Java security issues crop up when we talk about applets. Applets are Java's most pervasive version of mobile code (servlets have a bit of catching up to do). There are many things that untrusted Java applets should not be allowed to do and many resources to which Java applets should have only restricted access. The Java sandbox imposes these restrictions. With the introduction of Java 2, it is possible to treat applications as untrusted as well-running them inside the sandbox.

Applets can be related to the traditional client/server model in a straightforward manner: The Web server is the applet's server. It sends the applet to the client machine. The client is the machine on which the applet eventually runs. That means when you are surfing the Web and come across an applet, your machine is the client. This terminology is useful for explaining what applets are not allowed to do.

Note that the following list of no-no's defines only one commonly encountered kind of Java sandbox. Up until the advent of JDK 1.1, all Web-based applets were required to adhere to these rules (although enforcement was up to the browser being used). These days, sandboxes come in many assorted shapes and sizes. Untrusted applets that have not been granted special privileges are relegated to the default sandbox of the old days. Partially trusted applets can be given more leeway (or put another way, they can be given a larger sandbox to play in). As we shall see in Chapter 3, the size and shape of a Java sandbox is now at a Java user's complete discretion. Though we present the following list of constraints in terms of untrusted applets, untrusted applications can be run within the default sandbox as well. The sandbox, which is the base Java security model, implements the default constraints. If an untrusted applet has been loaded across the network and the default security policies are intact, the applet is not allowed to:

Read files on the client file system.
Write files to the client file system.
Delete files on the client file system, either by using the File.delete() method, or by calling system-level rm or del commands.
Rename files on the client file system, either by using the File.renameTo() method, or by calling system-level mv or rename commands.
Create a directory on the client file system, either by using the File.mkdirs() methods or by calling the system-level mkdir command.
List the contents of a directory.
Check to see whether a file exists.
Obtain information about a file, including size, type, and modification timestamp.
Create a network connection to any computer other than the host from which it originated.
Listen for or accept network connections on any port on the client system.
Create a top-level window without an untrusted window banner.
Obtain the user's username or home directory name through any means, including trying to read the system properties: user.name, user.home, user.dir, java.home, and java.class.path.
Define any system properties.
Run any program on the client system using the Runtime.exec() methods.
Make the Java interpreter exit, using either System.exit() or Runtime.exit().
Load dynamic libraries on the client system using the load() or loadLibrary() methods of the Runtime or System classes.
Create or manipulate any thread that is not part of the same ThreadGroup as the applet.
Create a ClassLoader.
Create a SecurityManager.
Specify any network control functions, including ContentHandlerFactory, SocketImplFactory, or URLStreamHandlerFactory.
Define classes that are part of packages on the client system.

Java applets are typically executed by Web browsers with embedded Java Virtual Machines (VMs) and runtime class libraries. Applets are downloaded by the browser and then executed by the built-in VM on the machine running the browser. The security of the system depends on these parts of the model: the Java language itself, the runtime class libraries, and the Security Manager of the browser. The next section examines how the Java compiler and runtime system restrict the creation and distribution of malicious code.

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help