Tomcat 4 Java SecurityManager Proposal (rev 2)
Use of the Java SecurityManager will be optional. The default
will be to start Tomcat with security to keep the folks at
bugtraq happy. Use without security at your own risk.
Currently the policy file is named catalina.policy,
Catalina is more of an internal development name for
Tomcat 4. To be consistent with Tomcat 3.x the policy
file will be named tomcat.policy instead of the current
catalina.policy.
Which raises a point, alot of environment variables in
Tomcat4 use CATALINA_ instead of TOMCAT_. Since Catalina
will be Tomcat 4, shouldn't these names be changed to
TOMCAT_ instead of Catalina?
Setting policies for internal Tomcat classes
--------------------------------------------
Security policies will be set using the tomcat.policy file. Security
checks will be based only on the codeSource of the class matching the
codeBase for JVM and Tomcat internal classes.
Example tomcat.policy entries affecting Tomcat internals
// javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
// java
grant codeBase "file:${java.home}/jre/lib/-" {
permission java.security.AllPermission;
};
// Tomcat core
grant codeBase="file:${tomcat.home}/server/-" {
permission java.security.AllPermission;
};
// Tomcat core common to both web apps and Tomcat
grant codeBase="file:${tomcat.home}/bin/-" {
permission java.security.AllPermission;
};
Setting policies for web application contexts
---------------------------------------------
A web application has its security based on either the default grant in
tomcat.policy or an entry for the context which uses the Context path
file URL as the codeBase. This policy will be in affect for any Class running
within the Context thread no matter which ClassLoader loaded the class
which triggered a security check. A default permission to read files in
the Context path is granted.
Tomcat 4 will come with a variety of example policy files,
policy files configured for unix and windows, example policy
files for lax and secure usage. The permissions in those
policy files have not yet been determined. What follows
is an example of how security for web applications are
configured.
// Permissions configured here are the maximum set of
// permissions that will be delegated to any web app
grant codeBase="file:${tomcat.home}/bin/servlet.jar" {
// To be determined
};
// Default permissions for a Context, all contexts have these permissions
grant {
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
};
// Additional Permissions for tomcat examples context
grant codeBase="file:${tomcat.home}/webapps/examples/- {
permission java.util.PropertyPermission "*", "read";
permission java.net.SocketPermission "*:80" "connect,resolve";
permission java.io.FilePermission
"${tomcat.home}/webapps/examples/WEB-INF/data/-","read,write,delete";
};
// Special permissions within a web app,
// This would contain a subset of the context permissions
grant codeBase="file:${tomcat.home}/webapps/examples/WEB-INF/lib/someHTTPpackage.jar" {
permission java.net.SocketPermission "some.host.com:80" "connect,resolve";
};
// Special permissions within a web app,
// This would contain a subset of the context permissions
grant
codeBase="file:${tomcat.home}/webapps/examples/WEB-INF/lib/someFileIOpackage.jar" {
permission java.util.PropertyPermission "*", "read";
permission java.io.FilePermission
"${tomcat.home}/webapps/examples/WEB-INF/data/-","read,write,delete";
};
In the above example the someHTTPpackage.jar would be allowed to make an
HTTP connection to "some.host.com", but not write files. And the
someFileIOpackage.jar would be allowed to write files in the
/WEB-INF/data directory but not make an HTTP connection.
This is because the security permissions allowed for the current class
are based on the intersection of its permissions with the permissions of
all the parent classes on the stack.
Security restrictions for using classes
---------------------------------------
StandardClassLoader will implement the SecurityManager.checkPackageAccess()
method to determine whether the ClassLoader has permission to access the
packages "sun.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"accessClassInPackage.{package name}", it will not be allowed to use a
Class in the package.
Security restrictions for defining classes
------------------------------------------
StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
method to determine whether the ClassLoader has permission to define a class
in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"defineClassInPackage.{package name}", it will not be allowed to define
a Class in the package.
Changing security policies at runtime
-------------------------------------
Anytime a Context is reloaded the security policies will be refreshed
from the tomcat policy file.
StandardClassLoader
-------------------
All of the code for implementing system, restricted, and allowed
checks will be removed. This will be handled by the SecurityManager.
Remove the ability to configure a contexts classloader in the
server.xml Context element.
Implement the URLClassLoader getPermissions() method when the
StandardClassLoader is used for a web application context.
A FilePermission "context root", "read" will be added to
those permissions configured for the context in the policy file.
Jasper JSP class loading
------------------------
Jasper will have the old 1.1 compatability code stripped out.
Jasper will be modified so that each individual jsp page
will have its own URLClassLoader. When each jsp page has
its own URLClassLoader we can remove the need to munge and version
the jsp java and class file names. We can also create directory
paths in the work dir for the context that matches the jsp page
path in the context. This will make it easier to view the
generated source for a jsp page. When a jsp page is recompiled,
a new instance of the URLClassLoader for that page will be
created.
Implement the URLClassLoader getPermissions() method.
A FilePermission "context root", "read" will be added to
those permissions configured for the context in the policy file.
These changes will also prevent implementation of a SecurityManager
from coupling Jasper to Tomcat like it is in the 3.x branch.
Future enhancements
-------------------
See if it is possible and secure to let an individual
web application set its security policies in its own
policy file located in its /WEB-INF/ directory.
Another alternative would be to create a tool in the
admin servlet that will allow editing of policy file
entries for a context. This tool would have permission
to rewrite the tomcat.policy file, updating the
codeBase entries for the context.
Status of the code
------------------
I have the security implementation in place for the
Tomcat core. I am now tracking down those places
where internal tomcat code has to be wrapped inside
a doPrivileged().
Once I get Tomcat 4 core done, I will move on to Jasper.
Thanks for all the feed back on my original proposal.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
