tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <g...@edamame.stinky.com>
Subject Re: What Do We Do With The User's Classpath?
Date Fri, 14 Jul 2000 13:10:18 GMT
> But look the other way:
> If you use a database, you probably need a database driver. The one
> included in your classpath will have the webapp protection domain, while
> the one in tomcat's lib will have network access. 

Whoa -- the default sandbox prevents network access?  That's pretty
heavy-handed.  I can think of lots of servlets that need to, e.g.,
access databases, or access other web sites, or access other data feed
services.

In any case, if the admin actually *wants* to keep a webapp from
accessing the network, then the webapp shouldn't be able to "cheat" by
using a system jdbc driver.

Your point is an interesting one, and related to the fact that Java
has ZERO support for different versions of a class.  What would solve
it is if we could specify, "I want org.foo.bar.Baz, version 2.1 or
higher", or "I want org.foo.bar.Baz, version 2.0 exactly", or "I want
org.foo.bar.Baz, I don't care what version", and so forth.

Until the Java language gets its act together on this, the best we can
do as container providers is allow the user to specify which exact
version he needs, by respecting his decision to include that in his
webapp/WEB-INF directory.  Not as much information as we'd like, but
the best we can do under the circumstances.


> Same for jaxp - the sandbox prevent access to some env variables, and jaxp
> may need those. Most javax. packages require some special priviledges.

There are only a few protected system properties.  The JAXP properties
should be accessible by all classes.


> It's also an issue of "who knows the environment better" ? Again in
> database case, the site admin probably knows the database version and have
> the right drivers installed. Your webapp is supposed to run on any web
> server, you can't know what driver to include.

Yes, you can.  If you need it to run on any database, then you accept
an InitParameter specifying the JDBC driver to load.  If you
specifically include a driver, then you are communicating your desire
to use this driver above all other compatible drivers. 

JDBC is another not-very-robust library, unfortunately.  The idea of
using static initializers to register drivers is moronic.  Again,
unfortunately, we're stuck with it.

This means that there's no way for a webapp developer to say "try to
find an appropriate JDBC driver, and if you can't find any other, use
this one".

Actually, it just occured to me that *because* of the moronic static
driver list, a clever sysadmin could force the webapps to use a
preferred driver simply by calling
Class.forName("org.moron.drivers.Foo") *before* the webapp loads.
Then the static DriverManager would find Foo rather than any other
drivers.  This is an interesting possible addition to Tomcat:
container initializer code, or servlets/webapps that must be
initialized in a given order.


> Antoher example for XML - assumin XSL is used, the server may use a smart
> xsl engine ( or one XML database as some people talk about), that does
> some caching or indexes. For example schema validation is very expensive,
> and some of it may be saved on disk. 

This is best left to the webapp.  XSL is not part of the servlet
container API.

A general caching XSL processor *might* be an interesting addition to
a specific app server (like Weblogic's general database connection
pool) but that has no business informing our decisions about Tomcat,
which by its nature can't include such container-specific features.

> > You miss the point.  The webapp's code is not going to be used except
> > by that webapp.  It's not "overriding" anything.
> 
> It can define a class in an existing package, and then will have access to
> package-level fields and methods. 

I'm amost 100% sure that's not true.  That was one of the earliest
exploits, and it was fixed around JDK 1.1.  Each classloader defines
its own namespace = package space.

> The XML components might require special priviledges that your app doesn't
> have ( reflection, introspection, etc). 

If they do, then you should be sure *not* to include them in your
(untrusted) webapp lib, so that you are sure to get the (privileged)
system-loaded versions.

> We should make a distinction between trusted apps ( if there is such
> thing, BTW), and untrusted ones. I'm concerned about untrusted code
> running on the server. ( of course, sometimes I think all code is
> untrusted, but that's a different story ).

All code is untrusted to some degree; that's why the language has
safety features like null pointer and array bounds checking.
Sandboxing security managers allow more granular control of what
programs can and can't do.  None of this is news, and I don't think any
of those points negate what I've been saying.


> > 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.
> 
> As I said, not having a breakin doesn't mean it's safe, and given the fact
> that most docs recommend a specific order I need more arguments. J2EE uses
> the same order ( and they also have the same app issues),

I'd love to see an rationale of the J2EE order.  Is this is the spec
or the ref impl?

>  JDK1.2 changed
> the classloader mechanisms ( you overload findClass, loadClass is not
> abstract but defined with this order ).

Hmm, I'll have to look at this.

> > Can you come up with a *specific* example of an exploit based on a
> > webapp-specific classloader?
> 
> Can you demonstrate there is no possible exploit :-) ? 

Well, I know that AppletClassLoader has been undergoing tests for 5
years or more, and it brings up all the same issues as a
webapp-specific classloader.


> I think it's a complex issue, and it takes time to understand all that's
> involved, and it's safer to use what other people do.

I agree, except that's it's only safer if we're sure *they* knew what
they were doing. :-)


-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

Mime
View raw message