Sorry not to get this out earlier ... comments intermixed.
Glenn Nielsen wrote:
> 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.
>
Will it be optional when Tomcat 4 is run by itself (either standalone or behind
a
web server) as well?
>
> 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;
> };
>
Note - to be technically correct, references to "tomcat.home" in the entries
above
should be "catalina.home" for Tomcat 4, to be consistent with the system
property
definition that is actually used.
>
> 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";
> };
>
Is this set of default permissions going to be easily configurable? I can
imagine
that this would be a popular choice for people who don't want to spend a lot of
time thinking about security. For example, you might want to grant all webapps
the
ability to connect to the network host and port required by your database
because
you use it in every app.
>
> // Additional Permissions for tomcat examples context
> grant codeBase="file:${tomcat.home}/webapps/examples/- {
> permission java.util.PropertyPermission "*", "read";
> };
Should the code base actually be restricted to ".../examples/WEB-INF/classes/-"
and
".../examples/WEB-INF/lib/-"? It means setting up two policy entries instead of
one if a particular app uses both JAR'd and unJAR'd classes, but I suspect that
is
somewhat unusual.
>
> 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.".
Is org.apache.jasper really special? It is loaded by the "Shared" classloader
(in
the Tomcat 4 classloader hierarchy) anyway, so it is already going to be
restricted.
And, a web app will need to be able to access these packages to utilize the JSP
servlet, and therefore execute JSP pages.
>
> 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.".
Same question re: specialness of Jasper, although I can see a stronger case for
prohibiting class *creation* in this package than class *access*.
>
> 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.
>
+1
It's only there as a placeholder until security manager support is available.
>
> Remove the ability to configure a contexts classloader in the
> server.xml Context element.
>
This goes against the grain with respect to configurability -- all other
components
of Catalina are pluggable at startup time. How about if we include the
necessary
requirements in the API contracts for the org.apache.catalina.Loader
implementation
when running under a security manager?
>
> 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.
>
Have you had a chance to measure or estimate whether there is a performance hit
from using a security manager (versus not) yet?
>
> 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:".
>
Does this imply that a webapp based on a file system (as opposed to running from
a
WAR directly, for example) is required? Current work on the Resources component
for 4.1 is to support generalization of this.
>
> The setContext() method will maintain a HashMap which maps
> ApplicationSecurity to its thread name.
>
Currently, the threads used for request processing are created and managed by
the
Connector component. And, because threads are recycled, the same thread will be
used for different contexts at different times (unless we change the threading
mechanisms).
>
> 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.
>
+1
>
> 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.
>
-1 -- this would prevent being able to deploy a web app directly from a WAR
file,
or from BLOBs in a database (either of which will be supportable by writing a
custom Resources implementation).
>
> 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.
+1 -- I don't like the munging that is currently needed.
> 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.
>
In 4.1, we're implementing a JNDI based DirContext for access to the resources.
Given that we have JNDI support, would it be possible to use that for looking up
the required security manager as well?
>
>
> 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.
>
That would be cool, although I'm a little hesitant on the "in its /WEB-INF/
directory" part -- IMHO security should be imposed on a webapp by the container,
rather than being defined by the webapp itself.
Overall, great work Glenn! I am loking forward to having this functionality
implemented in Tomcat 4.
>
> Regards,
>
> Glenn
>
Craig
>
> ----------------------------------------------------------------------
> 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]
