Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

By Raghavan N. Srinivas, JavaWorld.com, 12/15/00

This article, the third in the series, will cover the various requirements for securely running Java code downloaded from a network. Although mobile code is not a revolutionary concept, Java and the Internet present some unique challenges to computer security. The evolution of the Java architecture and its impact on core Java security was discussed in Parts 1 and 2. This article takes a different tack: a hands-on approach to tie all the concepts together by deploying a simple applet that writes to the local filesystem.

Java security evolution and concepts: Read the whole series!

• Part 1: Learn computer security concepts and terms in this introductory overview
• Part 2: Discover the ins and outs of Java security
• Part 3: Tackle Java applet security with confidence
• Part 4: Learn how optional packages extend and enhance Java security
• Part 5: J2SE 1.4 offers numerous improvements to Java security

At the example applet's core is public-key cryptography, introduced earlier in this series. Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine. We'll also discuss how policy files, which accord permissions and keystore, can be used as a repository for public and private keys. Moreover, we'll highlight the Java 2 SDK security tools and Netscape's signtool, since they enable deployment.

This article traces the evolution of Java security, beginning with application security in the initial release of Java 2 and moving on to the latest version of Java 2, version 1.3. This approach helps introduce the concepts gradually, starting with very simple concepts and culminating in a fairly advanced example.

This series does not intend to provide a comprehensive guide to computer security. Computer security is a multifaceted issue touching several disciplines, departments, and cultures. Investments in technologies should be followed up with investments in personnel training, strict enforcement of policies, and periodic review of the overall security policy.

Note: This article features a running Java applet designed to demonstrate applet security issues. Read below for more details.

Application security

Let's begin our investigation by looking at application security. In Part 2 we saw how Java security has evolved from a sandbox model to a fine-grained security model. We also saw that applications (local code) by default get a free reign and are not subject to the same control as applets (network-downloadable code), which are typically deemed as untrusted. In a change from the past, in Java 2 security applications can be optionally subject to the same level of control as applets.

First, a quick note about writeFile.java, the code used in this article to illustrate the security features in Java 2. This program is a slightly modified version of the applet code provided by Sun, available over the Web to illustrate some of the features of Java 2 security. The program, modified to provide application support, attempts to create and write a file on the local filesystem. Access to a local filesystem is screened by the security manager. We will see throughout this article how this particular operation can be permitted in a secure manner.

/**
  * By default, this raises a security exception as an applet.
  *
  * With JDK 1.2 appletviewer, 
  *  if you configure your system to grant applets signed by "Duke"
  *  and downloaded from the Java Software Website to write a file
  *  to your /tmp directory (or to the file named "C:\tmpfoo" on a 
  *  Windows system), then this applet can run.
  *  
  * @version JDK 1.2
  * @author  Marianne Mueller
  * @Modified by Raghavan Srinivas[Rags]
  */
import java.awt.*;
import java.io.*;
import java.lang.*;
import java.applet.*;
public class writeFile extends Applet {
    String myFile = "/tmp/foo";
    File f = new File(myFile);
    DataOutputStream dos;
  public void init() {
    
    String osname = System.getProperty("os.name");
    if (osname.indexOf("Windows") != -1) {
      myFile="C:" + File.separator + "tmpfoo";
    }
  }
  public void paint(Graphics g) {
     try {
         dos = new DataOutputStream(new BufferedOutputStream(new FileOutputStream(myFile),128));
       dos.writeBytes("Cats can hypnotize you when you least expect it\n");
       dos.flush();
       dos.close();
       g.drawString("Successfully wrote to the file named " + myFile + " -- go take a look at it!", 10, 10);
     }
     catch (SecurityException e) {
       g.drawString("writeFile: caught security exception", 10, 10);
        }
     catch (IOException ioe) {
          g.drawString("writeFile: caught i/o exception", 10, 10);
        }
   }
    public static void main(String args[]) {
     Frame f = new Frame("writeFile");
     writeFile     writefile = new writeFile();
     writefile.init();
     writefile.start();
     f.add("Center", writefile);
     f.setSize(300, 100);
     f.show();
    }
}

Running the bytecode generated in a Java 2 Runtime Environment, Standard Edition (JRE) will let the application modify the file on the local filesystem by default, since the default policy does not subject Java 2 applications to a security manager. This policy is justified because applications are typically locally generated code and not downloaded over the network. The following command line produces the window shown in Figure 1, indicating that the file was created and written into.

$ java writeFile

Figure 1. writeFile Application -- no security manager

To subject the code to the Java 2 security manager, invoke the following command line, which should produce the results indicated in Figure 2. Notice that the application generated a security exception caused by an attempt to modify the local filesystem. The explicitly included security manager generated the exception.

$ java -Djava.security.manager writeFile

Figure 2. writeFile Application -- including the security manager

The cases illustrated above represent extreme examples of security policy. In the former case, the application was not subject to any control; in the latter, it was subject to a very rigid control. In most cases it will be necessary to set the policy somewhere in between.

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq