BACKGROUND:
One of the unique (AFAIK) features of Tomcat 3.2 as a servlet container is the
fact that you can choose to run Tomcat under a Java SecurityManager (when
running under a Java2 JDK), with corresponding fine-grained control over the
resources that a particular web application can access. In addition, the
security manager can be used to constrain an application from accessing Tomcat
internals (for example, by trying to cast the HttpServletRequest it receives
back to the Tomcat internal implementation class).
This feature has long been on the wish list for 4.0, and recently Glenn Nielsen
<[EMAIL PROTECTED]> has volunteered to complete it. Those involved in
3.2 will recall that Glenn was also the primary "mover and shaker" in
implementing the security manager feature there.
Currently, as a stopgap security measure, Tomcat 4.0's web application
classloader implements some specific restrictions on access to particular Java
packages -- for example, an application level class is not allowed to load any
class in the org.apache.catalina.* hierarchy. While this does indeed protect
the internal implementation classes, it becomes redundant once running under a
security manager is installed -- the checkPackageAccess() method serves this
purpose in a much more powerful and controlled approach.
THE CURRENT SITUATION:
Currently, the internal object that implements the Java Servlet API objects
exposed to application components implement the corresponding API interfaces
directly. For example:
public class StandardSession
implements HttpSession, Session, Serializable {
...
}
so that, when an application calls request.getSession, an instance of this class
(suitably cast to HttpSession) is returned. The application cannot cast the
returned object to an org.apache.catalina.session.StandardSession, because of
the customized restrictions implemented in the web application class loader.
Switching to the security manager for protection requires a change in this
approach, because the security permissions of a StandardSession are based on
where *that* class was loaded from, and not from the interfaces it implements.
THE PROPOSAL:
For each Servlet API interface that represents an internal Catalina object
exposed to an application object, create a new
org.apache.catalina.facade.XxxxxFacade class according to the following basic
pattern:
* Pass the internal object to the constructor (the facade
will be a wrapper around it).
* Implement the appropriate servlet API interface (so the
facade object can be passed to application components)
* For each public method in the interface, implement a doPrivileged
block that calls the corresponding method on the underlying
internal Catalina object.
For example, the session facade object would look something like this:
package org.apache.catalina.facade;
import javax.servlet.http.HttpSession;
import org.apache.catalina.Session;
public class SessionFacade implements HttpSession {
protected Session session = null;
public SessionFacade(Session session) {
super();
this.session = session;
}
public String getId() {
AccessController.doPrivileged(
new PrivilegedAction()
{
public Object run() {
return (session.getId());
}
}
);
}
... same pattern for all other public methods ...
}
Additionally, the logic that implements request.getSession() would be modified
to look up and return the facade object associated with the current session,
instead of the actual StandardSession object itself.
RECOMMENDATION:
Implementing the remainder of the security manager logic in Tomcat 4.0 was part
of the agreed-upon original release plan, and Glenn has volunteered to undertake
the other changes necessary to Catalina and Jasper to make this happen (and
there are lots of them -- thanks Glenn!). It seems that adding the facade
classes, according to the pattern described above, will be necessary to complete
this work.
Therefore, I feel we should implement this change in Tomcat 4.0, and create a
new beta to allow testing of the results. This can be done in the same beta
release with the changes for the Valve API if that is also agreed upon.
However, I'm currently committed on other activities. In order to achieve these
changes in a timely manner, I'm looking for a volunteer to implement these
changes, if the proposal is accepted.
Comments?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
