tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <>
Subject Re: What Do We Do With The User's Classpath?
Date Fri, 14 Jul 2000 08:08:38 GMT

On Thu, Jul 13, 2000 at 05:56:23PM -0700, Costin Manolache wrote:
> I maintain my -1. Security should be more important than features.

We can have both, I'm pretty sure.

> If the site admin or the application embeding tomcat decide to use a certain
> CLASSPATH then a webapp can't override it ( by including it's own jars
> in front).

The XML Parser issue is a good counterpoint to this.  To clarify, a
hypothetical example:

Say Tomcat happens to be written to use JDOM beta 5

My webapp happens to be written to use JDOM beta 4, which has a
different and additional set of classes and exceptions, different
method signatures, etc.

If my code, running in a webapp, is forced to use the v1 classes, it
will break.  It must therefore be able to load JDOM classes from

> > > WEB-INF is not trusted and shouldn't be able to override any class that
> > > the sysadmin decides to put in the CLASSPATH.
> >
> > If we were talking about global code, I'd agree with you.
> >
> > Within an app, WEB-INF should be trusted because the app developer put those
> > classes there for a reason -- because the app needs them.
> No - the web server admin is trusted, because he is in charge with the site
> security.
> Webapps should _not_ be trusted, from the same reason applets
> are not trusted.

You miss the point.  The webapp's code is not going to be used except
by that webapp.  It's not "overriding" anything.

Thought experiment: If I wanted to, I could write a program that
changes the package name of any set of Java classes.  I could then use
my* classes which access* and include
the whole bunch in my WEB-INF/lib.  These classes would be sandboxed (!)
and my webapp code would work fine since there's no namespace clash.
I never pass these classes out of the webapp context -- how could I?

If I need to pass them in as parameters to system libraries, or call
superclass methods, then either they work because they
extend/implement the desired system classes/interfaces -- as loaded by
the system classloader -- or they fail (e.g. with a
ClassCastException) because they don't.

This is *exactly* equivalent to using a webapp-local classloader that
prefers WEB-INF/lib classes to system-classpath classes.  If you think
there's extra security risks in the classloader scenario, please spell
them out specifically so we can analyze them.

> Sandboxing is just one component of security. Preventing webapps from redefining
> classes is another component
> There are many ways someone could exploit this, and I'll not change my veto
> as long as security is on the goals list.
> ( think about package level accesses, etc)

I did, and package-level access is not an issue. The classes loaded by
the webapp classloader are in a different package, even though it has
the same name.

Can you come up with a *specific* example of an exploit based on a
webapp-specific classloader?

Alex Chaffee             
jGuru - Java News and FAQs
Creator of Gamelan       
Founder of Purple Technology
Curator of Stinky Art Collective

View raw message