Title: Security
1Security
2The need for security
- In most of the programming classes that weve
taken the emphasis has always been on getting the
job done and the idea of application security
is usually not considered. - Now that were 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 weve
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 its a bother - you cant write to the local hard drive
- you cant open a socket to where you want to talk
to - you cant access the local printer.
- This is your first exposure to the
SecurityManage, which has a different model for
applications and applets.
3The 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.getSecurityManag
er( ) if (security ! null)
security.checkWrite(name)
4Notice...
- The check only takes place when the
SecurityManager is active. - Java applications normally runs without a
SecurityManager, thats 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
isnt 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 e-mails all over the network.
5Running 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)
6problems 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
7AccessController
- 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(Permissio
n perm) java.security.AccessControler.chec
kPermission(perm)
8This 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
9policytool
- 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 thats
just my opinion)
10Telling 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.polic
ymypolicy.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.polic
y mypolicy.policy myapp
11URL specific permissions
- To assign permissions to files loaded from
specific locations well 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 -
12Signing 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