Last updated by admin 9 years ago
Author: Mark S. Petrovic, mspetrovic at gmail dot com Originally from:


The Java Runtime Environment provides well-documented means by which an application can run subject to a defined security policy. The purpose of this managed security is to selectively grant or deny the application access to specific system resources. For our purposes, resources are things such as system- and application-level properties, disk files, network connections, and class loading privileges, to name a few. Resources represent things the application either wants to know or do. It is the Java java.lang.SecurityManager class that enforces this resource access, with the rules of enforcement based on simple rules in a text-based human readable security policy file.

In this article we introduce and discuss a tool, a profiling security manager, that programmatically produces a starting point in crafting an effective security policy. This draft policy describes to what resources the application wants access and in what capacity (e.g., read, write). Our motivation is for both educational purposes and to develop a tool to learn what resources complex applications require access, and to what degree, to run according to their specification. The rules produced by the tool may be used as a point of departure in producing a policy file for these complex applications, presumably sufficiently complex that producing a fine-grained policy file without runtime information may be too difficult, or simply as a subject of study and examination.

The version of the profiling security manager discussed here requires a late-model Sun JVM, as it relies on reflection to acquire information on a particular system class's private member data. I used JSE 5, and the tool requires of type ProtectionDomain[] to exist.

The default Security Manager

By default a Java application runs with no runtime security manager. The application has full access to the machine resources, including disk, network, and application shutdown. Such broad access is easily restricted, however. An application can be forced to run under a "default" Java security policy by setting the option on the JVM command line.

Consider this simple application, designed to print the user's home directory represented by the System property user.home

public class PrintHome {
   public static void main(String[] argv) {
and with this runtime invocation
$ java PrintHome
Exception in thread "main" access denied (java.util.PropertyPermission user.home read)
at java.lang.SecurityManager.checkPermission(
at java.lang.SecurityManager.checkPropertyAccess(
at java.lang.System.getProperty(
at PrintHome.main(
The application fails to execute because the default security manager running with the default security policy forbids accessing the property user.home. Without the ability to read property user.home, the application cannot fulfill its intended purpose. This privilege must be granted explicitly in a runtime policy file.

Creating a policy file policy.txt, containing the single rule

grant codeBase "file:/home/cid/Projects/CustomSecurityManager/" {permission java.util.PropertyPermission "user.home", "read";};
and rerunning the application with a reference to the policy file solves the problem of access to user.home:
$ java PrintHome
The class PrintHome resides in the directory /home/cid/Projects/CustomSecurityManager/, and the rule permits any code originating in that directory to read system property user.home. As a result, the rule allows PrintHome to run as intended.

Introducing ProfilingSecurityManager

For simple applications, creating a policy file by hand is relatively straightforward and uninvolved. And even more so when one takes advantage of powerful URL specification rules allowed in the policy file. Using advanced rules notation, one can specify codebase URLs that refer recursively to entire directory trees. While such recursive URL specification is powerful, it can also mask to the human reader the true depth of the resource needs of the application. It is precisely that fine-grained depth that we seek.

We are interested in a programmatic method of determining precisely which resources to which an application requires access for it to successfully execute over its runtime trajectory. Toward that end, we introduce the custom security manager ProfilingSecurityManager. ProfilingSecurityManager extends java.lang.SecurityManager, but does not implement a security policy in the traditional sense. It instead determines what that security policy would be if the application were granted access to everything it requests at runtime -- under the application's intended conditions of use, of course.

To use ProfilingSecurityManager, specify it as the security manager when the application is invoked, noting that no policy file specification is necessary

$ java -classpath .:classes PrintHome

The custom security manager will write to System.out the rules needed in a policy file that will allow the application to run without throwing security violation exceptions:

grant codeBase "file:/home/cid/Projects/CustomSecurityManager/" {permission java.util.PropertyPermission "user.home", "read";};

Because the raw output from ProfilingSecurityManager can legitimately contain duplicate grant statements, and in the order the running application requires them, a Perl script is provided to aggregate, format, and output only unique rules, grouped by codebase. Rules must be processed after runtime, because only then is it known that the ProfilingSecurityManager is finished outputting new rules.

Rerunning the application with output processed by

$ java -classpath .:classes PrintHome  |
grant codeBase "file:/home/cid/Projects/CustomSecurityManager/" {permission java.util.PropertyPermission "user.home", "read";};