Thread Groups, Threads, and Security

The various restrictions on applets that we’ve mentioned in this chapter are a product of Java’s security mechanism. There are security mechanisms at several points in Java: in the language itself, in the virtual machine, and built into the Java API. As far as threads are concerned, only the security mechanisms of the API come into consideration, and we’ll examine how those mechanisms affect both threads and thread groups in this section. The enforcement of security is a prime reason behind the ThreadGroup class.

Java’s thread security is enforced by the SecurityManager class; security policies in a Java program are established when an instance of this class is instantiated and installed in the virtual machine. When certain operations are attempted on threads or thread groups, the API consults the security manager to determine if those operations are permitted. Prior to Java 2, there was no security manager in a Java application unless you wrote and installed one yourself; this is the reason that all the operations we’ve discussed are legal in Java applications. In a Java applet, there is typically a security manager in place that enforces particular restrictions.

Browsers and Security Managers

When you write a Java applet, you’re not given the opportunity to do anything with the security manager: the security manager is instantiated and installed by the browser itself and, once installed, cannot be changed.

But the Java specification does not specify what policies the security manager should enforce. Instead, the security policies at this level are a product of the particular browser. Different browsers may implement different levels of security: for example, the Netscape browser does not permit Java applets to read any files from the user’s local disk, but Sun’s HotJava browser allows the user to specify a list of directories in which the applet can read files.

The rule of thumb here is that the author of any Java application ultimately determines what security policy is in place; in the case of a browser, the author of the browser is the author of the application. Hence, different browsers can and do have different security models and policies.

In Java 2, there is still typically a security manager in place that enforces restrictions on applets, but there is also a new way to launch an application such that the application may be subject to a default security manager. Of course, applications may still install their own security manager (or run without a security manager) by launching themselves in the traditional way.

There is one method in the SecurityManager class that handles security policies for the Thread class and one that handles security policies for the ThreadGroup class. These methods have the same name but different signatures:

void checkAccess(Thread t)

Checks if the current thread is allowed to modify the state of the thread t.

void checkAccess(ThreadGroup tg)

Checks if the current thread group is allowed to modify the state of the thread group tg.

Like all methods in the SecurityManager class, these methods throw a SecurityException if they determine that performing the operation would violate the security policy. As an example, here’s the code that the interrupt() method of the Thread class implements (this is actually a conflation of code contained in the Thread class):

public void interrupt() {
    SecurityManager s = System.getSecurityManager();
    if (s != null)
        s.checkAccess(this);    // this is Thread.currentThread();
    interrupt0();
}

This is the canonical behavior for thread security: the checkAccess() method is called, which generates a runtime exception if thread policy is violated by the operation. Assuming that no exception is thrown, an internal method is called that actually performs the logic of the method.

Security and the checkAccess() Method

Both the Thread and ThreadGroup classes have an internal method named checkAccess(); this method, by default, calls the security manager’s checkAccess() method, passing either the thread or the thread group object.

The checkAccess() method within the Thread and ThreadGroup classes is public, so you can call it directly from any thread or thread group object if you want to check what security policy is in place.

The checkAccess() method within the ThreadGroup class is final; it may not be overridden. The checkAccess() method within the Thread class, however, is not final, meaning that you could override it and effectively change the security policy for your particular thread (but remember that this would only affect your thread class, and not other threads within the system).

Because there is only one method in the SecurityManager class that’s available to the Thread class and only one method that is available to the ThreadGroup class, a thread security policy is an all-or-nothing proposition. If the security manager determines that a particular thread is prevented from interrupting other threads, that thread is also prevented from setting the priority of other threads. However, the security manager can (and usually does) take into account contextual information about the thread—including its thread group—in order to determine the policy for the thread.

Table 10.1 lists methods in the Thread and ThreadGroup class that call the security manager to determine if an operation is legal. Note that this group of methods includes all methods that create or otherwise change the state of a particular thread or thread group, but does not include any method that provides thread information (such as the enumerate() methods or the getPriority() method). Hence, no matter what security manager may have been installed by the application, any thread is able to examine all other threads in the virtual machine; threads are only (possibly) prohibited from changing each other’s state.

Table 10-1. Thread and ThreadGroup Methods Affected by the Security Manager

Thread Methods

ThreadGroup Methods

Thread() [all signatures]

ThreadGroup() [all signatures]

stop() [both signatures]

stop()

suspend()

suspend()

resume()

resume()

interrupt()

interrupt()

setPriority(int priority)

setMaxPriority()

setDaemon(boolean on)

setDaemon()

setName(String s)

destroy()

Since the controls established by the security manager are completely at the discretion of the author of the Java application or Java-enabled browser, it is impossible to predict exactly what operations a thread might be able to perform. However, we’ll list some of the best-known cases here:

Java 1.0.2 and 1.1 applications

By default, applications in these releases have no security manager at all, and all threads are permitted to perform any operation on any other thread. This is not the case, of course, if the author of the application decides to install a security manager.

Java 1.0.2-based browsers

This category includes the 1.0.2 appletviewer, Internet Explorer 3.0, and Netscape 3.0. In these browsers, each applet is created within its own thread group. An applet is allowed to create a thread within its own thread group, and although an applet is allowed to create another thread group, it may not actually add threads into that thread group. Hence, Applet 1 in Figure 10.2 would be able to create subgroups 1 and 2, but not threads C and D. The fact that applets cannot add threads to any other thread group makes the ability to create a thread group useless in this case.

Possible threads in a Java-enabled browser

Figure 10-2.  Possible threads in a Java-enabled browser

Within the thread hierarchy, applet threads are allowed to modify any other thread group and any other thread as well, including threads in unrelated applets (e.g., thread A could modify thread B).

Java 1.1-based browsers

This category includes the 1.1 appletviewer, Internet Explorer 4.0, and Netscape 4.0. Although these browsers share a common reference base, there are differences in how they implement thread security. In the case of the appletviewer, each applet in these browsers is given a unique thread group, and the applet may create other thread groups that are installed into the thread group hierarchy under the applet’s thread group. In Figure 10.2, the browser would have created the applet 1 thread group, and the applet itself is allowed to create subgroups 1 and 2. The shaded box delineates the thread groups that belong to applet 1.

Any thread within the shaded box in Figure 10.2 is able to access any other thread within that box. Hence, thread A can manipulate threads C and D, and thread C can also manipulate its parent thread (thread A) as well as threads in any sibling thread groups (thread D). However, applet threads are not allowed to access the system or main threads, nor are they allowed to access any threads outside of their own set of thread groups (thread C cannot access thread E). In Netscape, however, applet threads are allowed to access threads of their parent (i.e., the main thread group). Oddly enough, however, applets are able to access and manipulate any thread group, including the system and main thread groups.

In Internet Explorer 4.0, this basic idea of thread security is slightly modified. To begin, IE 4.0 does not allow an applet to call the getParent() method in order to find out about the system and main thread groups. This is a change to the core API, which, as we mentioned earlier, does not make such a security check. So an applet thread in IE 4.0 can manipulate any thread or thread group that it can access, but that access is restricted to the applet itself (e.g., the shaded box in Figure 10.2).

In Netscape 4.0, applets are still not allowed to create threads within thread groups other than the default thread group created by the browser for the applet. In addition, the enumerate() method in Netscape 4.0 does not retrieve the correct set of threads for thread groups other than the applet’s thread group, so tracking down other threads outside the applet is impossible.

Java 2 applications

By default, Java 2 applications function the same way as 1.0.2- and 1.1-based applications: there is no security manager, and any thread is allowed to access any other thread.

If a Java 2 application is started with the -Djava.security.manager option, however, a default security manager is installed for it. In this security manager, permission to access another thread is strictly based on the thread hierarchy: any thread can manipulate any other thread that is below it in the hierarchy. Sibling threads may not manipulate each other, and a child thread may not manipulate its parent threads.

Java 2 also allows this default security manager to be configured via a series of policy files; normally these policy files include the files ${JAVAHOME}/lib/security/java.policy and ${HOME}/.java.policy. The policy files used by an application contain a mapping between the URLs where the application may obtain code and the permissions that the code loaded from those URLs should be granted. Hence, code loaded from a particular URL may be granted a permission of:

permission java.security.AllPermission

or a permission of:

permission java.security.RuntimePermission "thread"

Code that is granted one of these permissions will be able to access any other thread in the virtual machine.

In addition, in Java 2, the stop() method of the Thread class now performs an additional security check. In order to be able to call the stop() method on any thread, the URL from which the code was loaded must have been given a permission of:

permission java.lang.RuntimePermission "stopThread"

By default, this permission is granted to all code, but it’s possible for an end user or system administrator to change the policy file so that the stop() method cannot be called arbitrarily.

Java 2-based browsers

As of this writing, there are no Java 2-based browsers available, so it is unclear what thread security policies they might adopt. The Java 2 appletviewer policy, however, follows the same policy as the 1.1 appletviewer. That policy, too, may be additionally configured through the policy files, so that code loaded from certain URLs may be given permission to access any thread in the virtual machine.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset