tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Date Mon, 22 Jan 2001 19:58:55 GMT
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
> <glenn@voyager.apg.more.net> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Mime
View raw message