keymanager Print information about calls to the key manager.
trustmanager Print information about calls to the trust manager.
data For handshake tracing, print out a hex dump of each message.
verbose For handshake tracing, print out verbose information.
plaintext For record tracing, print out a hex dump of the record.
As you progress through the samples in the book, you can turn various options on in order to see more information about whats going on.
1.5 Summary
Security is a multifaceted feature of the Java platform. There are a number of facilities within Java that allow you to write a Java application that implements a particular security policy, and this book will focus on each
of those facilities in turn. These features are important within a Java−enabled browser, and they are also important with Java applications, particularly as applications become more distributed.
In addition, the security package allows us to create applications that use generic security features −− such as digital signatures −− for many purposes aside from expanding the Java sandbox. This other use of the security
package will also be a constant theme throughout this book. Chapter 1. Java Application Security
Chapter 2. The Default Sandbox
In this chapter, were going to explore the default sandbox that is used by most Java programs. The default sandbox is designed to allow an end user or system administrator to easily change the parameters of the
sandbox so that certain programs may run with a very specific set of permissions. If youre interested in how an applet running in the Java Plug−in can read a file, this chapter provides the information that you need. If
youre interested in having your own applications use the possibly modified sandbox, this is the place to be.
The information in this chapter is targeted to end users and system administrators: those are the people who are ultimately responsible for defining the security policies that their programs use. Except in special
circumstances, it is not possible to change security policies programmatically: in the default sandbox, there is no API that a developer can use that allows her to change a security policy. If you want your program to read
a local file, then you must tell the user who will run that program to modify the security policy of his machine before he runs your program. However, developers do need to understand the concepts and especially the
terms that we define in this chapter.
In the next few chapters, well discuss the programmatic details of how the sandbox is implemented; this will give you a better understanding of how Java security works and allow you to develop your own programs that
implement a different security policy. But well start with the default sandbox, an administratable, flexible model used by most Java programs.
2.1 Elements of the Java Sandbox
From an administrative point of view, the sandbox is composed of five elements: Permissions
A permission is a specific action that code is allowed to perform. Permissions may be specific e.g., the file C:\WINDOWS\Desktop\My Documents\Chapter2.fm can be read but not written or deleted or
very general e.g., the code can do anything it wants.
Permissions are composed of three elements: the type of the permission, its name, and its actions. The type of the permission is required; it is the name of a particular Java class that implements the
permission. Although no programming is involved in administering the default sandbox, administrators must know the Java class name of various permissions in order to allow code to
perform those operations.
A few permissions like java.security.AllPermission
, which allows code to do anything require no name. Otherwise, the name is based on the type of the permission; for example, the name
of a file permission is a file or directory name. The names of permissions are often specified as wildcards, such as all files in a directory or all hosts on the local network.
The actions of a permission also vary based on the type of the permission; many permissions have no action at all. The action specifies what may be done to the target; a file permission may specify that a
particular file can be read, written, deleted, or some combination of those actions.
Here are three examples of permissions. The first carries only a type; the second carries a type and a name; the third carries a type, a name, and a set of actions:
permission java.security.AllPermission; permission java.lang.RuntimePermission stopThread;
permission java.io.FilePermission tmpfoo, read;
Code sources Code sources are the location from which a class has been loaded along with information about who
signed the class, if applicable. The location is specified as a URL, which follows standard Java practice: code can be loaded from the file system through a file−based URL or from the network via a
network−based URL.
If code is signed, information about the signer is included in the code source. However, its important to note that the URL and signer information in a code source are both optional. Classes can be
assigned permissions based only on the URL from which the class was loaded, based only upon who signed the class, or a combination of both. Hence, it is not required that code be signed in order for it
to carry special permissions. The URL within a code source is called a codebase.
Protection domains A protection domain is an association of permissions with a particular code source. Protection
domains are the basic concept of the default sandbox; they tell us things like code loaded from www.oreilly.com is allowed to read files on my disk, code loaded from www.sun.com is allowed to
initiate print jobs, or code that is loaded from www.klflote.com and signed by Scott is allowed to do anything it wants.
Policy files Policy files are the administrative element that controls the sandbox. A policy file contains one or
more entries that define a protection domain; less formally, we can say that an entry in a policy file grants specific permissions to code that is loaded from a particular location andor signed by a
particular entity.
Programs vary in the way in which they define policy files, but there are usually two policy files in use: a global policy file that all instances of the virtual machine use and a user−specific policy file.
Policy files are simple files that can be created and modified with a text editor, and the JRE comes with a tool
policytool that allows them to be administered as well.
Keystores Code signing is one way in which code can be granted more latitude. The rationale behind code
signing is discussed in Chapter 7, but if you are assured that code you are running came from an organization that you trust, you may feel comfortable allowing that code to read the files on your disk,
send jobs to the printer, or whatever.
Signed code depends on public key certificates, and there is a lot of administration that takes place when you use certificates. The certificates themselves are held in a location usually a file called the
keystore. If you are a developer, the keystore is consulted to find the certificate used to sign your code; if you are an end user or system administrator, the keystore is consulted when you run signed
code to see who actually signed the code.
In the next few sections, well look at these elements in more depth.
2.2 Permissions
Every Java class carries a set of permissions that defines the activities that the class is allowed to perform. The parameters of the sandbox are wholly defined by these permissions. When a Java program attempts to perform
a sensitive operation, the permissions for all active classes are consulted: if every class carries the permission 22
