Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

  • Print
  • Feedback

Page 2 of 6

/**
  * 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.

You can accomplish an in-between policy using a policy file. To do so, create a policy file called all.policy in the working directory:

grant {
  permission java.io.FilePermission "<<ALL FILES>>", "write";
};


Running the same piece of code with the following command line will allow modification of the local filesystem:

  • Print
  • Feedback

Resources