1. Java Security cont’d

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

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

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

11. Policies and the Policy File cont’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 { 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); } }

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 writeFile policy.

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 " >", "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.