THE SECURITY MANAGER
The security manager is responsible for enforcing the security policies on Java programs. It controls access to resources on the platform, such as file systems and networks; environments on the host; and the creation of processes (FIG. 4). Most importantly, the security manager controls the creation of class loaders.

To accomplish this goal, the class method System.setSecurityManager() is used. The class Java.lang.SecurityManager is an abstract class. To implement a security policy, the user must extend this class. The following is an illustrative portion of a security manager. The complete code can be found on the previously listed web site:

public class URLMain throws MalformedURLException, ClassNotFoundException
{
SampleSM sem;

The class name that's used here for the security manager is SampleSM. We declare it to be of type SampleSM.

Hashtable clHashtable = new Hashtable();
URLClassLoader urlcl;
Class cl;
StringBuffer urlSB;
StringBuffer classFileSB;
int ch;
String urlString;
String classFileName;

The hash table keeps track of all class loaders and string buffers for reading URLs and class files.

ssm = new SampleSM(true);
System.setSecurityManager(ssm);
....
}

The following list summarizes the usage of the security manager:

• Java.lang.SecurityManager sets the security policy.
• For each resource, a check is performed to grant access.
• The security manager controls the creation of class loaders.
• Applications set the security manager once.
• The security manager is defined first and then implemented in code.

EARLY SECURITY ISSUES
Some of the historic distrust concerning Java security came from successful attacks on the JVM, which occurred in early implementations of the language. Back then, the integrity of the JVM could be compromised by loading files in the cache as though they were from a local file system. When class names began with a "/," anyone who had access to a local file system could place so-called "attack files" there. In addition, allowing access to a public ftp directory helped to compromise the JVM's integrity.

Another form of attack was applet-based. In this scenario, a class loader was installed from an applet. In turn, the class loader installed Java classes as trusted classes. This attack was made possible by a bug in the Java byte-code verifier. To reduce developers' security concerns, Sun Microsystems (www.sun.com) addressed these problems in later versions of Java.

In the security community, there's a routine joke that there's only one really secure machine. It's a machine that's enclosed in a room with no entry capability, no network connectivity, and no console. Sometimes, the joke also includes the requirement for no power.

These demands are obviously a little too stringent for the real world, in which Java is growing in popularity. Fortunately, early Java developers were very security conscious. They included protections for both language and code execution. The byte-code verifier, class loader, and security manager within the JVM all work in a cooperative manner to strengthen the security features of Java. Moreover, these features are accessible to developers. They allow them to design JVMs that meet specific security requirements for their own systems. The many protections that Java offers make it very unlikely that applications will be able to throw dirt in the proverbial sandbox.