Looks like there are enough +1's and no -1's to implement the architecture
change required for the SecurityManager.
I was hoping someone more familiar with the Tomcat 4 architecture would step
up to do this. But since one else has, I'll take a stab at it since I am
implementing the SecurityManager.
Regards,
Glenn
"Craig R. McClanahan" wrote:
>
> 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]
--
----------------------------------------------------------------------
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]
