Chapter 4. The Security Manager
In the next three chapters, were going to discuss how the sandbox of a Java application is implemented. The implementation of the sandbox depends on three things:
The security manager, which provides the mechanism that the Java API uses to see if security−related operations are allowed.
• The access controller, which provides the basis of the default implementation of the security manager.
• The class loader, which encapsulates information about security policies and classes.
• Well start by examining the security manager. From the perspective of the Java API, there is a security
manager that actually is in control of the security policy of an application. The purpose of the security manager is to determine whether particular operations should be permitted or denied. In truth, the purpose of
the access controller is really the same: it decides whether access to a critical system resource should be permitted or denied. Hence, the access controller can do everything the security manager can do.
The reason there is both an access controller and a security manager is mainly historical: the access controller is only available in Java 2 and subsequent releases. Before the access controller existed, the security manager
relied on its internal logic to determine the security policy that should be in effect, and changing the security policy required changing the security manager itself. Starting with Java 2, the security manager defers these
decisions to the access controller. Since the security policy enforced by the access controller can be specified by using policy files, this allows a much more flexible mechanism for determining policies. The access
controller also gives us a much simpler method of granting fine−grained, specific permissions to specific classes. That process was theoretically possibly with the security manager alone, but it was simply too hard to
implement.
But the large body of pre−Java 2 programs dictates that the primary interface to system security −− that is, the security manager −− cannot change; otherwise, existing code that implements or depends on the security
manager would become obsolete. Hence, the introduction of the access controller did not replace the security manager −− it supplemented the security manager. This relationship is illustrated in Figure 4−1. Typically, an
operation proceeds through the program code into the Java API, through the security manager to the access controller, and finally into the operating system. In certain cases, however, the security manager may bypass
the access controller. And native libraries are still outside the domain of either the security manager or the access controller although the ability to load those libraries may be restricted.
Figure 4−1. Coordination of the security manager and the access controller
4.1 Overview of the Security Manager
When most people think of Java security, they think of the protections afforded to a Java program −− and, more particularly, only by default to a Java applet −− by Javas security manager. There are other important
facets of Javas security story, but the role played by the security manager is of paramount importance in defining the security policy under which a particular program will operate.
On one level, the Java security manager is simple to understand, and its often summarized by saying that it prevents Java applets from accessing your local disk or local network. The real story is more complicated than
that, however, with the result that Javas security manager is often misunderstood.
On a simple level, the security manager is responsible for determining most of the parameters of the Java sandbox −− that is, it is ultimately up to the security manager to determine whether many particular operations
should be permitted or rejected. If a Java program attempts to open a file, the security manager decides whether or not that operation should be permitted. If a Java program wants to connect to a particular machine
on the network, it must first ask permission of the security manager. If a Java program wants to alter the state of certain threads, the security manager will intervene if such an operation is considered dangerous.
The security manager is used only if it is explicitly installed. When you run a Java application, specifying the −Djava.security.manager
option installs a security manager. The security manager is installed programatically by the appletviewer and the Java Plug−in.
Hence, this point cannot be overemphasized: Java applications at least by default have no security manager while Java applets again, by default have a very strict security manager. This leads to a common
misconception that exists in the arena of Java security: its common to think that because Java is said to be secure, it is always secure and that running Java applications that have been installed locally is just as secure
as running Java applets inside a Java−enabled browser. Nothing is further from the truth.
To illustrate this point, consider the following malicious code:
package javasec.samples.ch04; import java.applet.;
public class MaliciousApplet extends Applet { public void init {
try { Runtime.getRuntime .execrmdir foo;
} catch Exception e { System.out.printlne;
} }
public static void mainString args[] { MaliciousApplet a = new MaliciousApplet ;
a.init ; }
}
If you compile this code, place it on your web server, and load it as an applet, you will get an error reflecting a security violation. However, if you compile this code, place it in a directory, and then run it as an application
without using the −Djava.security.manager
option, youll end up deleting the directory named foo in your current directory.
[1]
As a user, then, its crucial that you understand which security manager is in place when you run a Java program so that you understand just what types of operations you are protected against.
[1]
Fortunately, for testing, this code doesnt execute binrm −r
or del .
. 54
4.1.1 Security Managers and the Java API
The security manager is a partnership between the Java API and the implementor of a specific Java application or of a specific Java−enabled browser. There is a class in the Java API called
SecurityManager java.lang.SecurityManager
which is the linchpin of this partnership −− it provides the interface that the rest of the Java API uses to check whether particular operations are to be
permitted. The essential algorithm the Java API uses to perform a potentially dangerous operation is always the same:
The programmer makes a request of the Java API to perform an operation. 1.
The Java API asks the security manager if such an operation is allowable. 2.
If the security manager does not want to permit the operation, it throws an exception back to the Java API, which in turn throws it back to the user.
3. Otherwise, the Java API completes the operation and returns normally.
4. Lets trace this idea with an example:
package javasec.samples.ch04; import java.io.;
public class Cat { public static void mainString args[] {
try { String s;
FileReader fr = new FileReaderargs[0]; BufferedReader br = new BufferedReaderfr;
while s = br.readLine = null System.out.printlns;
} catch Exception e { System.out.printlne;
} }
}
The FileReader
object will in turn create a FileInputStream
object, and constructing the input stream is the first step of the algorithm. When the input stream is constructed, the Java API performs code
similar to this:
public FileInputStreamString name throws FileNotFoundException { SecurityManager security = System.getSecurityManager ;
if security = null { security.checkReadname;
} try {
openname; open is a private method of this class } catch IOException e {
throw new FileNotFoundExceptionname; }
}
This is step two of our algorithm and is the essence of the idea behind the security manager: when the Java API wants to perform an operation, it first checks with the security manager and then calls a private method
the open
method in this case that actually performs the operation. Meanwhile, the security manager code is responsible for deciding whether or not the file in question should be
allowed to be read and, if not, for throwing a security exception: Chapter 4. The Security Manager
Kategori