Java Security cont’d

1. Java Security cont’d

2. UsingSecurityManager • 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.

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

4. Thecode 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.

5. A simple example that only permits writing to a file named "temp" in the current directory

6. 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"); } }

7. The TestSecurityManager class installs a TempfileSecurityManager through the System.setSecurityManager method. • If we run TestSecurityManager, wecould 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 property • because it only looks at the filename being opened. • A better implementation would also look at the context in which the file is opened.

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

9. 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"); } }

10. Policiesand the Policy File • This version of the class is different in that is does not callSystem.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 toour 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"; };

11. Policiesand 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.

12. Java Application Security

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

14. 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 Sun • It 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.

15. import java.awt.*;import java.io.*;import java.lang.*;import java.applet.*;public class writeFile extends Applet {    StringmyFile = "/tmp/foo"; File f = new File(myFile);    DataOutputStreamdos;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);        } }

16. 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(); }}

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

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

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

20. 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 writeFilepolicy.

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

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