Thread security in Java is really rather simple--at least it was until Java 2 came along. First we
will explain how security worked prior to Java 2 and then go into some of the details of the new
security features of Java 2.
Prior to Java 2 the primary focus of security was the SecurityManager class. The
SecurityManager class is used to enforce a security policy for Java programs and in most
cases is never modified by programmers. The SecurityManager class is usually defined and
activated when a Java VM starts. When a Java method tries to access a vulnerable resource in the
Java VM, one of the check methods in the SecurityManager class is called. If the check
method permits the requested action, the check method will return silently. However, if the check
method does not permit the requested action, the method throws a security exception. Using the
Thread class as an example, when the checkAccess() method is called from the Thread class,
it calls into the SecurityManager class and executes the checkAccess() method. If the
calling thread is allowed access, the checkAccess() method simply returns. If the calling
thread is not permitted, the checkAccess() method throws a SecurityException. Code
Example 10-1 shows how the code would look in the calling thread.
Example 10-1 Checking for Security Violations
Thread A;
try {
A.checkAccess();
} catch (SecurityException se) {
System.out.println("Thread access error: " +
se.getMessage());
}
This may seem rather trivial; well, it is. The SecurityManager class defines the security to be
implemented for the entire Java VM. In most cases the SecurityManager class has been
defined for you. For example, when you are using the Netscape browser to execute Java code, the
developers at Netscape have defined the SecurityManager for you. In this case, you can't
modify or remove the SecurityManager. In most cases the SecurityManager will be
defined and installed for you; this is the case when the Java VM is started for you. For example,
the Java VM is started for you when you run code via a browser or appletviewer. If you start the
Java VM yourself, for example from a command line, you are responsible for defining and
installing a SecurityManager.
By default, a SecurityManager is not installed in the Java VM. Depending on how you
execute Java code, you may have to install your own SecurityManager. If some other program
controls the Java VM, in most cases that program will install a SecurityManager. This is the
case with browsers; since the browser controls the Java VM, it will probably install a
SecurityManager. If the Java VM is not controlled by another program, in most cases you will
have to install a SecurityManager. This is the case when you write your own Java applications.
If you don't define a SecurityManager in your application, your program will have full reign
of the Java VM.
The main problem with the security mechanism in previous versions of Java is that you do not
have fine-grained control over the security of your program. The other side of this is that users
could not define what level of security they were willing to accept. For example, if a Java
application was executed on your machine, it had full access to the machine just as a traditional C
application would. The security mechanisms in Java 2 have solved these problems.
Now that we have a bit of history, let's talk about how security works in Java 2. Java 2 exploits the
concept of protection domains. Java has always had the concept of protection domains. That is,
different code in the Java VM can have different levels of security. The simple case of this is the
Search WWH :
