Rfc 768

Chapter 3. Java Language Security
The first components of the Java sandbox that we will examine are those built into the Java language itself.
These components primarily protect memory resources on the user's machine, although they have some
benefit to the Java API as well. Hence, they are primarily concerned with guaranteeing the integrity of the
memory of the machine that is hosting aprogram: in a nutshell, the security features within the Java
language want to ensure that a program will be unable to discern or modify sensitive information that may
reside in the memory of a user's machine. In terms of applets, these protections also mean that applets will be
unable to determine information about each other; each applet is given, in essence, its own memory space in
which tooperate.
In this chapter, we'll look at the features of the Java language that provide this type of security. We'll also
look at how these features are enforced, including a look at Java's bytecode verifier. With a few exceptions,
the information in this chapter is largely informational; because the features we are going to discuss are
immutable within the Java language, there are fewer programmingconsiderations than we'll find in later
chapters. However, the information presented here is crucial in understanding the entire Java security story;
it is very helpful in ensuring that your Java environment is secure and in assessing the security risks that Java
deployment might pose. The security of the Java environment is dependent on the security of each of its
pieces, and the Java languageforms the first fundamental piece of that security.
As we discuss the language features in this chapter, keep in mind that we're only dealing with the Java
language itself −− following the common thread of this book, not all security features we're going to discuss
apply when the language in question is not Java. If you use Java's native interface to run arbitrary C code,
that C code will beable to do pretty much anything it wants to do, even when it violates the precepts outlined
in this chapter.

3.1 Java Language Security Constructs
In this chapter, we're concerned primarily with how Java operates on things that are in memory on a
particular machine. Within a Java program, every entity −− that is, every object reference and every
primitive data element −− has an access levelassociated with it. To review, this access level may
be:

private
The entity can only be accessed by code that is contained within the class that defines the entity.

Default (or package)
The entity can be accessed by code that is contained within the class that defines the entity, or by a
class that is contained in the same package as the class that defines the entity.

protected
Theentity can only be accessed by code that is contained within the class that defines the entity, by
classes within the same package as the defining class, or by a subclass of the defining class.

public
The entity can be accessed by code in any class.
The notion of assigning data entities an access level is certainly not exclusive to Java; it's a
hallmark of many

42

Chapter 3. Java LanguageSecurity

object−oriented languages. Since the Java language borrows heavily from C++, it's not surprising
that it would borrow the basic notion of these access levels from C++ as well (although there are
slight differences between the meanings of these access modifiers in Java and in C++).
As a result of this borrowing, the use of these access modifiers is generally thought of in terms of
theadvantage such modifiers bring to program design: one of the hallmarks of object−oriented
design is that it permits data hiding and data encapsulation. This encapsulation ensures that objects
may only be operated upon through the interface the object provides to the world, instead of being
operated upon by directly manipulating the object's data elements. These and other design−related...