Glenn Nielsen wrote:
> 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.
>
I would suggest that we do *not* do this.
As the web site says, Tomcat = Servlets + JSP. There are a significant number of
people who
want to package the servlet container portion of Tomcat (i.e. Catalina) without the JSP
environment. That's fine -- they are welcome to the code -- but at that point it is
not
Tomcat any longer. It is, however, Catalina at that point being configured -- so it
makes
sense to use CATALINA_HOME, "catalina.sh", and so on.
>
> 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?
>
See above.
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
