The Security Manager
The above two layers mainly ensure that the Java system is not subverted by invalid code. However, they do not provide any mechanisms to protect against malicious code in a network program. For a moment, imagine that a client is aware of a sensitive file (e.g., /etc/passwd) that is available on the Web (HTTP) server's host system. The client may request that file and, if a security policy is not implemented to protect against this, the server will be able to satisfy the client's malicious request.

This is just one kind of malicious instruction that the first two layers do not protect the server's host system against. However, given that Java code will adhere to the restrictions imposed by the Java runtime system, a security policy can be devised and implemented at the application level. This will allow us to state what sort of requests a Java client program can or cannot perform. For example, it will allow us to state if a client is allowed to read the sensitive file "/etc/passwd".

Building a Security Policy
The Java Development Kit does not come with a security policy mechanism that is ready for use by your applications. Rather, you have to define one yourself and implement it. However, the SecurityManager class, which is part of the java.lang package, provides the necessary mechanism for creating a custom security manager that defines tasks that an application can and cannot do.

The SecurityManager class is an abstract class (non-instantiable) that allows application developers to implement a security policy. The SecurityManager class provides you with a mechanism to establish a specific security policy that is suitable for the level of trust for a particular program. It provides the ability to create objects to determine if an operation that a program may perform is permitted.

The SecurityManager class provides many methods for performing acts to enforce a security policy, some of which are shown in Table 1.

As you can see in table 1, most of the methods in the SecurityManager class start with the word check. When your application uses one of the Java APIs to perform some tasks (say reading files), the methods that start with the word check are actually called by the Java APIs before performing certain sensitive operations (such as reading, writing or deleting files). If an operation is not allowed, a SecurityException will be thrown.

When writing a client/server application, make sure you devise a coherent security policy that states what the client is allowed to do with the server. For example, make sure that the server's machine file system is not at risk when performing clients' requests. Take into account any request that a client may perform. For example, if you are building an HTTP server, you must make sure that clients cannot get the file "etc/passwd" if they request it!

Building a Security Manager
Once a coherent security policy has been devised, implementing it is not particularly complicated. The SecurityManager class already provides abstract methods that we must override with new code that implements our security policy.

Example
As a realistic example of implementing a security policy and a custom security manager, let me remind you of the article "Programming an HTTP Web Server with JavaHTTP" (JDJ, Vol. 2, Issue 5), by Joseph DiBella. Note that this is not to criticize that article, but rather to show a realistic example where devising and implementing a security policy is a must.

DiBella wrote a nice article about how to implement a simple Web server in Java. Having written a Web server myself and taking into account that Security is a state of mind, the first thing I asked myself after reading Joseph's article was: "Is this HTTP server secure?" The answer was no. If you are up for some pure experimentation, try to compile the code and run it. Then, via your favorite Web browser (I use Netscape), try to fetch some documents that the server should not be allowed to ship to clients. For example, on my workstation, I ran the above server and I wanted to see if I could get the password file (which is normally located at /etc/passwd), so I constructed the following URL and gave it to Netscape to fetch: http://myHostName:8080/../../../../../etc/passwd. The HTTP server found the file and shipped it back to the client (Netscape) and I got it displayed on the screen. Note that the number of ".." depends on how far I am from the root directory and the countdown starts from the directory you ran the Web server from.

However, this is not all. A client's request may look like this:
http://myHostName:8080//etc/passwd (note the extra slash after the port number). This says that I want to start from the root directory and get the file "etc/passwd", which is an easier way (than the use of "..") to get to the password file. Surprisingly, the server was able to deliver the requested file to the client.

A Security Policy
In a standard Web server, you certainly do not want people to be able to fetch documents that they are not allowed to. In other words, you want the server to have access to only a certain area of the file system, not the whole thing. In our case, we would like to prevent people from using ".." as well as "/" as the first character of the requested file in their URLs.

Building Our SecurityManager
In order to create a secure environment for our Web server, we would subclass (inherit) the SecurityManager and override some of its methods. The SecurityManager class has various methods, such as: checkAccess(), checkRead(), checkWrite(), checkConnect()...etc. In our case, we would want to disallow people from constructing URLs that would permit them to read files which they should not be able to read. That is, as demonstrated above, we want to prevent them from using ".." in their URLs, as well as "/" as the first character of the requested document. Thus, our new SecurityManager can be constructed, as shown in Listing 1.

It is important to note that when defining a custom security manager, you must override some or all of the permission checking methods depending on the policies enforced by the security manager. By default, all of the methods will simply throw a SecurityException, meaning that the operation is not allowed, with the exception of the checkTopLevelWindow() method which returns a boolean value. It is important to note that when you include a method, such as checkAccess(), with an empty implementation body, as shown in Listing 1, then that means the operation is allowed.

If, on the other hand, you would like to allow an operation but in a more restricted form, then you must provide your own implementation. For example, if your security manager allows clients to read files, then it must provide its own implementation for checkRead(), as shown in Listing 1. The implementation provided overrides the existing checkRead(String) and allows the client to read files from the server, provided that the path to the file does not contain ".." and the requested file does not start with a slash.

Installing Our Security Manager
Once a custom Security Manager is built, it is time to install it in our Web server. Installing it is as easy as adding a line in the main() body of the program as follows:

System.setSecurityManager(new ServeSecurityManager());

The ServeSecurityManager class, also shown in Listing 1, throws a security exception once a user is trying to read a file they do not have access to. Thus, we need to catch that security exception. This new exception must be caught in the fileOpened() method in the HTTP server code.

Conclusion
Java is the language of choice for building future client/server applications. Security is a major concern in every client/server system. The SecurityManager class, part of the java.lang package, is an abstract class that allows application developers to easily implement their own custom security policies.

References
1. Yellin, F., Low Level Security in Java: http://www.javasoft.com/sfaq/verifier.html
2. SecurityManager class. http://www.javasoft.com/products/jdk1.1/docs/api