Java Security cont’d

Using SecurityManager

The basic SecurityManager architecture is simple. Throughout the JDK, the Java security team had to:

Identify operations in the code that might pose a security risk. Find places in the code

where checks could be placed to guard these operations (but do so with the smallest number of bottlenecks).

Throw an exception if the caller is not allowed to proceed.

For example: Writing to a file on a user's local hard drive is an operation that needs to be secured.

All file writes must at some point involve a FileOutputStream constructor.

//from the JDK 1.3 source... public FileOutputStream (String name, boolean append) throws FileNotFoundException {SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkWrite(name); } //go on and actually construct the object

The code above is a representative example of the security checks we can find throughout the JDK.

Before the actual work of the constructor begins, there is a check with the System class

to see if a security manager is installed.

If there is one, the constructor calls an appropriate method on the security manager,

passing in any additional information that might influence the outcome.

In the case of writing to a file, the relevant method is checkWrite() and the extra information is the name of a file.

A simple example that only permits

writing to a file named "temp" in

the current directory

import java.io.*; class TempfileSecurityManager extends SecurityManager { public void checkWrite(String name) { if (!("temp". equals(name))) { throw new SecurityException ("Access to '" + name + "' denied"); } } }

public class TestSecurityManager { public static void writeFile(String name) throws IOException

{ System.out.println ("Writing to file " + name); FileOutputStream fos = new FileOutputStream (name); //write something here... fos.close(); }

public static void main(String[] args) throws IOException { System.setSecurityManager(new TempfileSecurityManager()); writeFile ("temp");

writeFile ("other"); } }

The TestSecurityManager class installs a TempfileSecurityManager through the System.setSecurityManager method.

If we run TestSecurityManager, we could see that the writeFile method works fine when the file passed in is

named "temp“ but fails when "other" is passed in as the filename.

The TempfileSecurityManager is simple, but it has a major weakness.

A particular capability is either granted to all the code running in the VM, or not granted at all.

Real systems need to assign different abilities to different pieces of code running in the same VM.

For example, it would be nice to have a logging facility that could write to a logfile,

but prevent any other code from writing to the local file system.

The TempfileSecurityManager cannot handle this propertybecause it only looks at the filename being opened.

A better implementation would also look at the context in which the file is opened.

Policies and Policy File What JDK 1.1 needed was a security system that was

declarative instead of procedural; a system where application developers and system administrators

describe what security settings they want instead of how to implement them.

JDK 1.2 and later provide declarative, policy-based security through a new class java.security.AccessController

.AccessController and related classes build on the pre-existing SecurityManager.

We can write our own security manager,if we choose to rely on the new, policy-based security,

we do not have to write any code. Starting with JDK 1.2, SecurityManager is a concrete class that

delegates to the AccessController to implement a fine-grained, context-based security policy.

Sun Microsystems provides a reference implementation of this policy that is controlled by a text file called the policy file.

import java.io.*;//the variation of the TestSecurityManager class public class TestSecurityManager { public static void writeFile(String name) throws IOException{ System.out.println("Writing to file " + name);FileOutputStream fos = new FileOutputStream(name);//write something here... fos.close(); } public static void main(String[] args) throws IOException {

writeFile ("temp");writeFile ("other"); } }

Policies and the Policy File This version of the class is different in that is does not call

System.setSecurityManager. Therefore: the class should run without security checks and

write to both the "temp" and "other" files.To enable 1.2 security, we can either use setSecurityManager to

install an instance of the SecurityManager class, or specify the following property on the command line:

java -Djava.security.manager TestSecurityManager By default, permissions granted to our local code are minimal

. So we see an AccessControlException when trying to access the "temp" file

java.security.AccessControlException: access denied (java.io.FilePermission temp write) In order to enable writing to the temp file, we need to specify a

policy in a policy file, which might look like this: //file my.policy grant { permission java.io.FilePermission "temp", "write"; };

Policies and the Policy Filecont’d

We can instruct the virtual machine to use this policy file by specifying the java.security.policy property:

java -Djava.security.manager - Djava.security.policy= my.policy TestSecurityManager With this command line, we should be able to write to the

"temp" file, but not to the "other" file.

Notice that this new solution provides the same capability as the custom TempfileSecurityManager class.

However, we didn't have to write any Java code to use the policy file.The only work was making the correct settings in the policy file and on

the command line.

Java Application Security

Java Application Security Applications (local code) by default get a free

control Applications are not subject to the same

control as applets (network-downloadable code)

applets are typically considered as untrusted.

Security applications can be optionally subject to the same level of control as applets

in a change from the past version, in Java 2

Java Application Security The Java code given below illustrates the security features

in Java 2. This program is a slightly modified version of the applet code

provided by SunIt is available over the Web to illustrate some of the features of Java 2

security. That program

is 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. This particular operation can be permitted in a secure manner.

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";    }  }       catch (SecurityException e) {      g.drawString ("writeFile: caught security exception", 10, 10);        }     catch (IOException ioe) {          g.drawString("writeFile: caught i/o exception", 10, 10);        } } 

   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);     }

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, JRE will let the application modify the file on the local filesystem by default,

Because 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 figure indicates that the file was created and written into when runned as: java writeFile

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 below.

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

writeFile Application

including the security manager

Comparing two examples

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.

java.security.manager tells the JVM to use a Java security policy file.

java.security.policy tells the JVM the location of the Java security policy file to use.

The argument is the fully qualified name of the Java security policy, which in this case is writeFile policy.

Set the Policy differently We can accomplish an in-between policy using a policy file. We can 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:

java -Djava.security.manager -Djava.security.policy= all.policy writeFile

In the example above: The application was subject to the

security manager But the overall policy was governed by the

policy file, which allowed all files on the local

filesystem to be modified. A stricter policy might have been to allow

modification of only the relevant file -- tmpfoo in this case.