Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
Work on implementing this proposal is in progress. Comments please?
Tomcat 4 Java SecurityManager Proposal
Tomcat 4 will require the Java SecurityManager, use of the
SecurityManager will be optional when Tomcat is embedded in
another application.
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;
};
grant codeBase "file:${java.home}/jre/lib/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/server/-" {
permission java.security.AllPermission;
};
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.
// 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";
};
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.
ApplicationSecurityManager
--------------------------
This Class is a replacement for the default SecurityManager and extends
class SecurityManager.
It does a normal permission check first, if that fails it takes additional
steps if the current thread is for a web application context.
When a Context is started or stopped it will need to register with
the ApplicationSecurityManager using methods setContext() and
removeContext().
Context threads will be named threads with the name set to the
string representing the file URL of the Context. i.e.
"file:/usr/local/tomcat/webapps/examples".
All other threads should be named with a name which doesn't
start with "file:".
The setContext() method will maintain a HashMap which maps
ApplicationSecurity to its thread name.
When a permission check fails the security manager will see if
the current thread or any of its parent threads are for a web
app context. If it is for a context, the permission check will
be done using the permissions for that web application context.
If the permission is for file read, permission will be granted
for the context root directory.
With the changes to jasper below, the normal permission check
will work for everything except when a web app context is
using a class from the shareable ClassLoader. So the overhead
of using the Thread naming conventions to perform the second
web app context security check should be minimal, most of the time
if the first permission check fails, the second one would also.
Jasper JSP class loading
------------------------
Jasper will have the old 1.1 compatability code stripped out.
The work directory will be moved inside the web application context
/WEB-INF/ directory. This will make security configuration easier
and security checks more efficient. The jasper work dir for a context
would be /WEB-INF/work/. This should be safe, other important files
which need to be protected from outside view are stored in
WEB-INF such as java properties files and class files.
/WEB-INF/work will not be added to the contexts class path.
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.
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.
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]
