Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Sender: glenn@zathras.earthdome.org
Message-ID: <39AA663A.D780CA49@voyager.apg.more.net>
Date: Mon, 28 Aug 2000 08:16:42 -0500
From: Glenn Nielsen <glenn@voyager.apg.more.net>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: TC3.3: Proposal - remove tomcat.loader
References: <39A55F93.1C6A1E3A@yahoo.com>
 <39A60060.C1F90DA3@voyager.apg.more.net> <39A6957B.340D8996@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Costin Manolache wrote:
> 
> > I like the idea of a separate DependManager to handle class
> > reloading.  Will we be able to implement that for Jasper so
> > we can clean up its class name mangling?
> 
> I've already done a prototype ( the JspInterceptor), but I don't have
> the energy to go on with it :-(.
> 
Is this checked in to CVS?  Maybe I'll take a look at it sometime.

> > The above won't work unless the libs/classes with additional permissions
> > implement doPriviledged().  For example, if the compiled
> > JSP's in the work dir have very limited permissions, the
> > classes/jar files the JSP uses (say a taglib), will inherit
> > the security policy of the JSP unless the class/lib implements
> > doPriviledged().
> 
> That's a bit tricky ( for 1.1 use), but IMHO security is more
> important. I think you shoud go ahead and we'll fix 1.1 later.
> 

Nothing to go ahead with, I was speaking in general about how security
policy inheritance works.

> > In general, I think a Context (webapp) should be considered
> > entirely user land.  I would prefer not to have to rely on
> > file permissions/ownership for security in user land.
> 
> Yes, I totaly agree. No permission to the user ! :-)
> Unfortunately this doesn't seem to work in real world.
> 
> > Administratively it is easier to set one security policy for
> > an entire Context (webapp).  If there are any libs/classes that need
> > additional priviledges, I would rather install them globally,
> > then selectively implement doPriviledged() and/or a special
> > Permission class.
> 
> Let's make distinction between permissions granted automatically
> and special cases. For autmatic it is almost the same ( i.e. we
> can go back to using server.xml to specify per/context
> properties, but in PolicyInterceptor we'll need to grand them
> to classess, lib, workdir )
> 
> In a "secure" configuration the webapps should get no special
> permissions, except maybe some libraries installed
> at the server level - but we need a bit of flexibility.
> 
> > I would be for switching to the URLClassLoader _if_ we can use
> > the policy file as is.  Couldn't we use getPolicy()/setPolicy()
> > when creating/reloading the Context to add the additional ProtectionDomains?
> > Perhaps sub class URLClassLoader to catch newly installed libs/classs so
> > that their ProtectionDomain can be setup using getPolicy()/setPolicy()
> > before passing the request along to the System URLClassLoader.
> > (Could this be done in LoaderInterceptor?)
> 
> I think that can be done.
> 

Great.  +1 on changing to URLClassLoader as long as the following behaviour
still works.

1.  The security policy can be configured for a Context in tomcat.policy by
    specifying the Context webapp directory as the codeBase.  PolicyInterceptor
    creates a Policy for all jar files found in WEB-INF/lib and 
    WEB-INF/classes during Context init which reflects the security policy
    configured for the Context codeBase.  (or uses the tomcat.policy grant
    with no codeBase if none exists for the Context codeBase).

2.  Policy for new jar files installed in WEB-INF/lib is dynamic.  If a new jar
    file is added to a Context WEB-INF/lib directory after Tomcat was started,
    a new Policy entry is created for it reflecting the policy for the Context.

3.  We don't have to configure SecurityManager Permissions in server.xml.  I
    liked the change you made to my original code that allowed security policy
    to be set in tomcat.policy.

> I would try first to play with getPolicy/setsPolicy, and extend URLClassLoader
> as a last resort.
> 
> ( the other advantage and reason for URLClassLoader - I want tomcat
> to run with minimal priviledges, and extending URLClassLoader requires
> ClassLoaderPermission. The other reason is that I would trust more an
> un-altered URLClassLoader ).

I have been playing around with setting specific Permissions for Tomcat
instead of AllPermissions.  You can make Tomcat more secure this way,
but you still need to configure almost all the RuntimePermissions.  But
it did allow me to prevent Tomcat from reading/writing any files outside
of the tomcat home directory and limit what remote web servers could 
connect to the Tomcat Connector on port 8007.  It would be interesting
at some point to profile Tomcat w/o using the Java SecurityManager to
Tomcat with the Java SecurityManager implemented to see what the tradeoff
is between security and performance.

> 
> > I just finished working through the security/policy issues.
> > You may have noticed a few SecurityManager related commits recently.
> > You might want to review the tomcat-security.html file I
> > added to the doc directory.
> > (Thanks for removing the work dir write FilePermission from
> > the default Context permissions)  I was even considering looking
> > into a TomcatPermission class.  We might be able to use that to
> > address the Tomcat object reuse security problem you mentioned.
> 
> +1 - but keep in mind JDK1.1
> 

How about creating an interface called InternalSecurity().  There could
be an InternalSecurity11.java that implements the current admin=trusted
code, and an InternalSecurity12.java that implements security using
the SecurityManager with special Tomcat Permission classes.

Glenn

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