Access Control
As we noted at the beginning of this chapter, the heart of the Java security architecture is access control: untrusted code simply must not be granted access to the sensitive parts of the Java API that would allow it to do malicious things. As we’ll discuss in the following sections, the Java access control model evolved significantly between Java 1.0 and Java 1.2. Since then, the access control model has been relatively stable; it has not changed significantly since Java 1.2. The next sections provide a brief history of the evolution of Java security as it developed from Java 1.0 to Java 1.2, which marked the last major changes to the security model.
Java 1.0: The Sandbox
In this first release of Java, all
Java code installed locally on the system is trusted implicitly. All
code downloaded over the network, however, is untrusted and run in a
restricted environment playfully called “the
sandbox.” The access control policies of the sandbox
are defined by the currently installed
java.lang.SecurityManager
object. When system code is about to perform a
restricted operation, such as reading a file from the local
filesystem, it first calls an appropriate method (such as
checkRead( )
) of the currently installed
SecurityManager
object. If untrusted code is
running, the SecurityManager
throws a
SecurityException
that prevents the restricted
operation from taking place.
The most common user of the
SecurityManager
class is a Java-enabled web
browser, which installs a
Get Java in a Nutshell, 5th Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.