On Sat, 23 Jun 2001, Glenn Nielsen wrote:
> > I believe there are important security issues, but I'm sure the spec took
> > this into consideration - so probably I'm wrong ( of course, this will be
> > easy to verify later on, there are quite a few ways someone could try to
> > exploit a reversed order - but again I'm sure this was taken care of and
> > it'll be just the fun of trying :-).
> >
>
> Yes there are security issues related to the Servlet 2.3 spec webapp CL.
> Fortunately, the Java SecurityManager can protect you if you use
> checkPackageDefinition() in the CL. This can prevent a Servlet 2.3 webapp
> CL from redefining system or other sensitive classes.
That's only part of the problem and only part of the solution :-) I'm not
going to argue to much about this - the archives of tomcat-dev are
available, no need to repeat :-)
It all depends on how you define 'sensitive classes' - what is not
sensitive and how you decide so ? It's turning the problem around, from
"don't trust anything" to "don't trust specific things" - and that's
considered dangerous by some other people.
I'm looking forward to see implementations and how they'll address the
issues ( I'm very curious about drivers and libraries that
require extra permissions - are you going to grant the permission on the
whole app ? Add them to the list of "sensitive" ? The loader
implementation will be fun - at least ).
For now, tomcat3.3 should be ok - the recomended configuration is with
minimal classes in common and classpath, webapps should be self-contained
or use standard APIs - and those APIs are considered "sensitive". That
mean whatever is placed in Classpath and common is sensitive and can't be
overriden ( and it is sensitive indeed - as it usually have bigger
permissions than the app itself ). The container is in a separated
classpath, so you can use anything inside without interfering with the
webapps, and with the ProfileLoader it's easy to have fine control over
what you make available to each webapp.
Since what's "sensitive" is not defined ( I assume you can say 'javax and
java', but then you're open to big problems ) the behavior should be ok
even from servlet2.3 perspective - we treat everything in common/system as
sensitive ( no risk taken ), and the app class loader has nothing to
override :-)
Costin
