|
Java™
by example!
|
|
|
What is a SecurityManager?
The SecurityManager contains a number of methods that check whether a certain operation is permitted, eg. checkRead, checkWrite, checkPropertyAccess. For example, when you are instantiate an object of the class FileInputStream to open a file, the security manager will be consulted to see if you allowed to do so:
For applications, no security manager is installed and hence the checkRead in the FileInputStream constructor will not be executed and the file is successfully opened. The following program shows that no security manager is installed and thus will output null:
To make sure your program is using a default security manager, use the switch -Djava.security.manager when your run your program or do it programmatically by calling System.setSecurityManager.
Look at the output of the following program with and without a security manager:
The program tries to output the System properties "java.version" and "test" (a dummy one).
Notice that without a security manager installed, it runs as we wish. With a default security manager installed, it correctly returns the System property "java.version" but throws an AccessControlException when trying to read the property "test". Why is that?
First, let's look at the getProperty method in the System.java source file:
It checks for a security manager and if one exists, it uses checkPropertyAccess to determine whether it is allowed to read the property key that is passed in as an argument. Permissions are granted through policy configuration files. There is a system-wide policy file and a single user policy file. The system-wide policy file is located at JAVA_HOME/lib/security/java.policy and the user policy file can be found at USER_HOME/.java.policy (in my case, I found it in C:\WINDOWS). The locations of these two policy files are specified in the file JAVA_HOME/lib/security/java.security (in my case, I found it in C:\jdk1.2.2\jre\lib\security). When starting up, the system policy is loaded first and the user policy is added to it. If neither of these policy files are present, a built-in policy is used, which is the same as the sandbox policy.
Now, if you look at a part of the system wide policy file java.policy:
To find out how these policy files are structured, look at the document Permissions in the Java 2 SDK or Permissions and Security Policy.
Notice that a permission is granted to read the System property "java.version". That's why we can read in this property even with a security manager installed. No permission has been given to read the property "test", so this results in an Exception.
You can make the JVM use additional policy configuration files with a command-line argument:
For example, we could add an extra permission to read the property "test".
mypolicyfile:
result:
mypolicyfile can be either made with a simple text editor or with the graphical JDK tool policytool.
If you want the JVM use only your policy file and not the system-wide nor the user policy, use a double equal sign:
This would result in an exception when trying to read the system property "java.version".
The policy file can be highly customized. It should be structured as follows:
For more information on policy file syntax look at the document Default Policy Implementation and Policy File Syntax
( Note: the principal entry is useful for assigning permission based on who is running the code as opposed to where the code is coming from or who signed it, look at the JAAS category for more information. )
For example, to only grant permissions to our Main class located in C:\ we would write:
Running our Main in C:\test would result in an AccessControlException: Access Denied.
Further Information
Author of answer: Joris Van den Bogaert
Comments to this answer are only viewable by members. Login or become a member!
|
|
|
|
|
In-house 
