Security CS-328

The need for security In most of the programming classes that we’ve taken the emphasis has always been on getting the “job” done and the idea of application security is usually not considered. Now that we’re building more and more network centric applications security must be considered. Since its inception, security has been a part of Java and there has been a security model (whether or not we realized it) in place whenever we’ve written a Java application. Probably the first time you run into the idea of security in Java is in writing your first applet, at this point it’s a bother –you can’t write to the local hard drive –you can’t open a socket to where you want to talk to –you can’t access the local printer. This is your first exposure to the SecurityManage, which has a different model for applications and applets.

The SecurityManager The Securuty Manager class has been in Java since version 1.0 –part of java.lang contains many checkNNNN( ) methods –where NNNN represents an operation that could possibly be harmful ex. checkWrite( ) check whether writing to the local hard drive is enabled. If the operation is OK then the method returns normally, if nor a SecurityException is thrown. Public FileOutputStream( String name.boolean append) throws FileNotFoundException { SecurutyManager security = System.getSecurityManager( ); if (security != null) { security.checkWrite(name); }

Notice... The check only takes place when the SecurityManager is active. Java applications normally runs without a SecurityManager, that’s why everything is allowed from an application What if you found a jar file out on the internet that looked like it had some useful classes and methods in it. Would you down load it and just use it as part of your application or would it be better to test it installed under a SecurityManager first and make sure that there isn’t a Trojan Horse hidden in the jar that might do something harmful to your machine (like wipe out you hard drive or use your machine to send out thousands of s all over the network.

Running the SecurityManager The SecurityManager can be run two ways: –from the command line when you initially run your program java -Djava.security.manager MyApp –or explicity from your code Public static void main( String[] args) { SecurityManager manager = new SecurityManager(); System.setSecurityManager(manager); This installs the default/base security manager, it could have just as easily installed a subclass of the default that custonized the rules by overloading the methods (Java 1.0)

problems with doing this… The main problem with this is that the security rules were defined directly in the Java source code, so you had to get a copy of the source code and modifiy it and modify and add to the base classes and things get really messy What was needed was a SecurityManager that kept the rules externalized so that they could be easily modified without modifying the code. In most ways the Java 2 SecurityManager still operates the same way –checkNNNN methods are still called before possibly dangerous operations. What is different is that the checkNNNN methods delegate the decision on throwing SecurityException to the AccessController class –java.security package

AccessController Instead of have many methods corresponding to the many possibly harmful operations it has a single checkPermission( ) method. –Passed a parameter that indicates the kind of operation requested this parameter is an instance of a Permission subclass –the specific subclass will identify the operation and encapsulate any parameters needed – for example… the previous call to checkWrite –will result in an instance of FilePermission being passed to checkPermission( ) and that FilePermission object will describe the type of access (read or write) requested and identify the specific file involved Public void checkWrite(String file) { checkPermission(new FilePermission(file, “write”)); } public void checkPermission(Permission perm) { java.security.AccessControler.checkPermission(perm) }

This is pretty much the story... except, how does the AccessController determine whether to throw a Security Exception? This is determined by what it finds in the currently active policy file(s) a policy file is a text file containing a set of permission descriptions each permission contains the name of a particular Permission subclass ex to grant permission to write to c:\myapp\data.txt grant{ permission java.io.FilePermission “ c:\myapp\data.txt”, “write”;

policytool To save you the bother of creating permission files with a text editor the JSDK provides a GUI tool for creating policy files I find it just as easy to use wordpad (but that’s just my opinion)

Telling the JVM to use the policy Two ways: –modify the java.security configuration file that the JVM uses at start up look in /lib/security beneath you home directory –specify it when you start the JVM java -Djava.security.manager -Djava.security.policy=mypolicy.policy myapp this will cause the JVM to use mypolicy.policy in addition to whatever it finds in java.security to use the specified file in place of java.security use = = java -Djava.security.manager -Djava.security.policy= =mypolicy.policy myapp

URL specific permissions To assign permissions to files loaded from specific locations we’ll include a URL ex. To allow only classes loaded from the local C:/java directory to write to output.txt Grant codebase “file:/C:/java/” { permission java.io.FilePermission “C:/myapp/outpot.txt”, “write” } This will apply to all classes in c:/java but not to classes in a.jar file in c:\java; to get them add an “*” at the end of the URL; to incluse child directories us a “-”

Signing JAR files Its also useful to assign permissions based on the originator of the specific code being used, this can be done by adding a digital signature to the jar file use the keytool and jarsigner utilities from the JSDK this same approach can be used to assign user specific permissions