radioAe6rt

Update 7 Nov 2006 This post has been superceded by an update here.

Sometime back I did some brute force work on building a Java security policy file for Tomcat apps by an iterative analysis of the catalina.out log file. Recently I became interested in this problem again, and wrote a custom security manager to solve it.

Here is SM, a custom security manager that enforces no policy, but rather indicates what permissions on what resources your application wants. The output of SM is a policy file “grant” statement per resource by codeBase. Here is a custom startup script for Tomcat that provides for using SM as the security manager. The idea is to specify SM as the security manager for an app, cover the runtime trajectory of the app during testing, capture the rules generated by SM, then revert back to a “real” security manager with those rules in place.

Some comments

1. This is a first attempt at creating a custom security manager for purposes of generating a policy file. It is not optimized, almost certainly has issues, but is a reasonable start.
2. The tool should not be used without thinking. It’s likely only a good start on a security policy, one which must be tweaked for production use. I tested it casually with the ROOT webapp that comes bundled with Tomcat. The tool generated reasonable rules, but ymmv. No doubt the output must be reconciled with and appended to the shipped rules that are already configured in conf/catalina.policy.
3. Rules are written to stdout.
4. SM can be used as easily with apps run from the command line as it can with Tomcat. Use the same sort of security options to the JVM.
5. SM works by inspecting the stack when permissions are checked, writing a rule for all non-bootstrap classes on a chain requesting access to a given resource . SM loads the classes in question for purposes of ascertaining their CodeSource. That is, in which file or jar file does the class originate. Classes SM cannot load are silently ignored. SM used in containers such as Tomcat, which uses multiple classloaders, may encounter classes it cannot load (Hmm. Is that actually true?). See Class Loading in Tomcat.
6. Any class in the Java runtime rt.jar is exempted from rule creation.
7. One would probably want to write some sort of perl/python script to parse the output to aggregate rules on codebases. Same goes for eliminating duplicate rules, of which there are many in the raw output. This is a start on that.

Feedback welcome.

Update:

Here is a tarball that contains simple command line code you can use to test SM. The command line app flexes some basic operations: gets a couple properties and makes a network connection.

Untar it somewhere, then do

$ sh make.sh
$ sh run.sh | parsecodebase.pl
grant codeBase "file:/home/petrovic/Projects/CustomSecurityManager/classes/com/homosuperiorus/" {
   permission java.io.FilePermission "/dev/random", "read";
   permission java.io.FilePermission "/dev/urandom", "read";
   permission java.io.FilePermission "/home/petrovic/Projects/CustomSecurityManager/classes/com/homosuperiorus/JarCode.class", "read";
   permission java.io.FilePermission "/home/petrovic/Projects/CustomSecurityManager/externaljar.jar", "read";
   permission java.io.FilePermission "/home/petrovic/java/jdk/jdk1.5.0_06/jre/lib/i386/libnet.so", "read";
   permission java.io.FilePermission "/home/petrovic/java/jdk/jdk1.5.0_06/jre/lib/net.properties", "read";
   permission java.lang.RuntimePermission "loadLibrary.net", "";
   permission java.lang.reflect.ReflectPermission "suppressAccessChecks", "";
   permission java.net.NetPermission "getProxySelector", "";
   permission java.net.NetPermission "specifyStreamHandler", "";
   permission java.net.SocketPermission "[http://www.petrovic.org]", "resolve";
   permission java.net.SocketPermission "[http://www.petrovic.org]:81", "connect,resolve";
   permission java.security.SecurityPermission "getProperty.securerandom.source", "";
   permission java.security.SecurityPermission "putProviderProperty.SUN", "";
   permission java.util.PropertyPermission "impl.prefix", "read";
   permission java.util.PropertyPermission "java.home", "read";
   permission java.util.PropertyPermission "java.net.preferIPv4Stack", "read";
   permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
   permission java.util.PropertyPermission "java.net.useSystemProxies", "read";
   permission java.util.PropertyPermission "java.security.egd", "read";
   permission java.util.PropertyPermission "java.version", "read";
   permission java.util.PropertyPermission "socksProxyHost", "read";
   permission java.util.PropertyPermission "sun.net.spi.nameservice.provider.1", "read";
   permission java.util.PropertyPermission "user.home", "read";
};

grant codeBase "file:/home/petrovic/Projects/CustomSecurityManager/externaljar.jar" {
   permission java.util.PropertyPermission "java.version", "read";
};

What I find curious are the permissions which have no “actions” (e.g., read or write), such as

permission java.security.SecurityPermission "putProviderProperty.SUN", "";

What might these mean?

But it all makes for some interesting output.

Update: I wrote up in more detail the motivation and means for this utility.

[tags]tomcat, tomcat security, java security, java policy files[/tags]