ClassLoaders

[cm...@yahoo.com]

Hi,

I did some more reading ( and thinking ) about the class loader, and it
seems the order is not enough.

Probably what is needed is a JDK1.2-specific class loader ( where Package
can be used ), and a way to also make sure that the webapp can't define
classes in any package that is also defined by the system. ( sort of
sealing - unfortunately only few pacakges use the "Sealed" and I'm not
sure how this works in a multi-class loader env, i.e who have to enforce
the sealed attribute)

We'll end up with some more config, but I do want to implement context
isolation and sandboxing, and probably I'll just start with a new
classloader.

Regarding ordering - I change my vote to -0, as long as you implement the
different ordering in a configurable classloader that you can plug in
instead of the default one, per context.

That mean I am ok with any class loaders that you use in a controled
manner for your trusted ( or believed-to-be-trusted) applications. The
plug in mechanism for that is not complete in 3.2, but it would be nice to
have it in 3.3.

( Interesting reading: http://www.dyade.fr/fr/actions/VIP/JS_pap2.html
)


Costin

Re: ClassLoaders

[cm...@yahoo.com]

> Something to remember,
> 
> 	A package (from an access standpoint) is defined as a 
> classloader namespace and package name.  Classes in the same package
> but from different classloaders cannot access each others package 
> access restricted methods.

You have a package in your CLASSPATH, it gets all the permissions ( by
being "system" ). Then you have a class in your app, in the same package.
It calls a package level method on a class from the system package. 

Since the class is not in your webapp, it will be loaded by the system
class loader ( or by the webapp classloader from a location that has
permissions). Now your webapp that didn't had any permissions just got
outside of the box.

Also, I think your quote is incomplete - there is something about
classes loaded by a parent loader.


Does anyone on this list feel confident he understand all the details of
class loader and the type system in Java ?  As I read more I have more
doubts about what I thougt I know... 

Costin

Re: ClassLoaders

[Paul Speed <ps...@progeeks.com>]

Something to remember,

	A package (from an access standpoint) is defined as a 
classloader namespace and package name.  Classes in the same package
but from different classloaders cannot access each others package 
access restricted methods.

	-Paul

cmanolache@yahoo.com wrote:
> 
> Hi,
> 
> I did some more reading ( and thinking ) about the class loader, and it
> seems the order is not enough.
> 
> Probably what is needed is a JDK1.2-specific class loader ( where Package
> can be used ), and a way to also make sure that the webapp can't define
> classes in any package that is also defined by the system. ( sort of
> sealing - unfortunately only few pacakges use the "Sealed" and I'm not
> sure how this works in a multi-class loader env, i.e who have to enforce
> the sealed attribute)
> 
> We'll end up with some more config, but I do want to implement context
> isolation and sandboxing, and probably I'll just start with a new
> classloader.
> 
> Regarding ordering - I change my vote to -0, as long as you implement the
> different ordering in a configurable classloader that you can plug in
> instead of the default one, per context.
> 
> That mean I am ok with any class loaders that you use in a controled
> manner for your trusted ( or believed-to-be-trusted) applications. The
> plug in mechanism for that is not complete in 3.2, but it would be nice to
> have it in 3.3.
> 
> ( Interesting reading: http://www.dyade.fr/fr/actions/VIP/JS_pap2.html
> )
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: ClassLoaders

[Janco Tanis <se...@coas.com>]

"Craig R. McClanahan" wrote:

>
> A couple of ideas (that are already implemented in the Catalina class loader)
> are worth thinking about:
>
> * "Restricted" classes:  the class loader refuses to load
>   these classes at all  [org.apache.tomcat.*].  The intent
>   is to prevent a "bad guy" servlet from being able to cast
>   the HttpServletRequest and HttpServletResponse objects
>   passed to the service() method to their internal Tomcat
>   equivalents, and get into mischief.
>

I would guess that you need at least a SecurityManager to protect introspection of
you internal classes and invoking methods on them using the reflection package ?

janco

Re: ClassLoaders

[Costin Manolache <cm...@yahoo.com>]

>
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > What happens if 12 months from now someone finds a way to get around the
> > class loader hack or the VM will act differently ( or is this class
> > loader based on some existing language specification) ?
>
> If this happens, the entire Java sandboxing world is in trouble.

???

Have you found any document/specification mentioning this feature?
I haven't, and I tried quite a bit. All class loaders I found ( applet,
rmi, j2ee ) use the reverse order and all docs are quite strong on 
recommending it. 

It's a nice hack - if it works, but even if it does, it is still less
flexible than a facade approach. And basing the whole security on it ... 
And of course, it looks beautifull on paper.


> > Well, there is a simple solution - use tomcat :-)
>
> This has nothing to do with classloaders, but I have been working with
> Tomcat for about six months, and I have had occasion to peek at the code and
> try to figure a few things out. I consider myself an average programmer, but
> it is really confusing to pick and prod my way through the current state of
> the source code. Maybe, it's just a case of poor documentation, but the
> fascade interface, to me, seems very difficult to trace through.

Yes, it is. It can be cleaned up, documented, explained - but don't
confuse 
the code quality with the desing quality. It's probably my fault for
writing
bad code, but IMHO those who designed tomcat did a very good job.

Take a look at Apache - and the latest design discussion ( byte
brigades, etc)
on newhttpd. The user interface should be simple and clean ( and of
course, the 
Interceptors in tomcat still need a bit of work ), but it doesn't seem
the apache
people are afraid of using complex alghoritms if they are the right
solution.

QuickSort is not so easy to understand ( compared with BubleSort for
example), 
but I would argue that it is a better solution.  

> On the other hand, after reading Craig's introduction to the Catalina design
> and seeing all of the interfaces defined, I must say I feel much more at
> home there. I see where the pluggability and promise of a true componetized
> architecture shines. I think this clarity of design will encourage many,
> many more developers to work with Tomcat and contribute their code to make
> it the best container out there.

Sure, an introduction to sorting using BubleSort will also look shiny.
It remains to be seen if long term the model will scale to make it the
best sorting
alghoritm out there. 

( I don't want to argue about "true" components, try to work with the
code first )

> It's rather obvious that you two are protecting turf here, but I see trouble
> brewing when this thing comes up for a vote. From a manager's point of view,
> is the group defining the goals for Tomcat 4.0? Without this in hand, there
> won't be a way to judge which approach (or a combo of the two) is best for
> Tomcat 4.0. 

I just hope people that will vote on this will spend the time to
understand the design
and will think about that for a while. And facts do not change too much
 regardless of people vote.

Tomcat is now just a "hobby" for me, so I don't have to worry about
tomcat 4.0,
and I know exactly what are my goals for a servlet container. If it will
be 
called tomcat4.0 or fooBar is not so important. 


> I'm not sure if fragmenting the development into two different
> camps would result, but with such strong-held beliefs from both developers,
> I wonder what the future holds.

Well - the development _is_ fragmented and ( with all the great
"componentization" ) it doesn't seem we are able to share even non-core
components like session manager or http adapters. Tomcat does use
adapters
 ( yet another great pattern), and it can plug any external components, 
but right now it would be easier to integrate jigsaw components than
catalina.

There are great benefits anyway - ideas, a backup, and making sure 
that the result will have a certain level of performance and 
security. And the bar will raise high enough to be sure that 4.0 will be 
a great container, whatever the code base it use ( probably in few 
months we'll start to see the actual benefits of using the design
tomcat use, and I hope I'll be able to finish a documentation).

Costin

RE: ClassLoaders

[James Cook <ji...@iname.com>]

I feel like I'm errantly stepping in between the heavyweights in a sparring
match. Can't wait 'til the gloves come off. :-)

> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> What happens if 12 months from now someone finds a way to get around the
> class loader hack or the VM will act differently ( or is this class
> loader based on some existing language specification) ?

If this happens, the entire Java sandboxing world is in trouble.

> Well, there is a simple solution - use tomcat :-)

This has nothing to do with classloaders, but I have been working with
Tomcat for about six months, and I have had occasion to peek at the code and
try to figure a few things out. I consider myself an average programmer, but
it is really confusing to pick and prod my way through the current state of
the source code. Maybe, it's just a case of poor documentation, but the
fascade interface, to me, seems very difficult to trace through.

On the other hand, after reading Craig's introduction to the Catalina design
and seeing all of the interfaces defined, I must say I feel much more at
home there. I see where the pluggability and promise of a true componetized
architecture shines. I think this clarity of design will encourage many,
many more developers to work with Tomcat and contribute their code to make
it the best container out there.

It's rather obvious that you two are protecting turf here, but I see trouble
brewing when this thing comes up for a vote. From a manager's point of view,
is the group defining the goals for Tomcat 4.0? Without this in hand, there
won't be a way to judge which approach (or a combo of the two) is best for
Tomcat 4.0. I'm not sure if fragmenting the development into two different
camps would result, but with such strong-held beliefs from both developers,
I wonder what the future holds.

jim

Re: ClassLoaders

[cm...@yahoo.com]

> > :-)
> >
> > So that's the magic way Catalina handles downcasting... Have you tested
> > this ? What VMs ?
> >
> 
> The attached test servlet attempts to downcast the HttpServletRequest
> that it

Sure, simple downcasting doesn't work, but are you sure smarter methods
don't work either ? 

> > I prefer the proven Facade pattern to prevent downcasting.
> 
> Facades are a fine design pattern.  However, in this case, they would
> require a lot
> of cross-object method calls between the facade and the internal
> representation,
> which aren't necessary when they are one object that can reference
> instance
> variables directly.

Sure, but security by design is sometimes better than class loader
hacking, and it's also more flexible - you have fine control  (i.e in your
code, not somewhere in the VM - maybe!) over what access a servlet has.

What happens if 12 months from now someone finds a way to get around the
class loader hack or the VM will act differently ( or is this class
loader based on some existing language specification) ? 


> > > * "Application" classes:  currently, the class loader looks
> > >   in the application classpath first (WEB-INF/classes and
> > >   WEB-INF/lib and then loads from the parent class loader
> > >   if they are not found.  (See below for more about ordering).
> >
> > And of course you have a solution to deal with permissions ?
> >
> 
> Not yet.  An implementation based on the Java2 permissions architecture
> is required
> before Catalina is ready to be proposed.

Well, there is a simple solution - use tomcat :-)

> Do you have some examples where using FacadeManager really makes a
> performance difference?

Soon ( probably in 3.3 ). Tomcat 3.2 just removes some bad code and reuses
few objects ( and prepares the code for the future optimizations).

I'll send a list of proposals for 3.3 soon, right now I'm in XML-land.
( can anyone read the schema specs ? Is it english ? )  

Costin

Re: ClassLoaders

["Craig R. McClanahan" <Cr...@eng.sun.com>]

cmanolache@yahoo.com wrote:

> > Catalina's application class loader (org.apache.tomcat.loader.FileClassLoader)
> > distinguishes three kinds of classes.  The lists for the first two kinds are
> > configurable (not yet from server.xml, but in the code) with defaults in
> > square brackets.
> >
> > * "Restricted" classes:  the class loader refuses to load
> >   these classes at all  [org.apache.tomcat.*].  The intent
> >   is to prevent a "bad guy" servlet from being able to cast
> >   the HttpServletRequest and HttpServletResponse objects
> >   passed to the service() method to their internal Tomcat
> >   equivalents, and get into mischief.
>
> :-)
>
> So that's the magic way Catalina handles downcasting... Have you tested
> this ? What VMs ?
>

The attached test servlet attempts to downcast the HttpServletRequest
that it
receives to the underlying Catalina interface that is represented. 
Compile it
against the Catalina classes directory (and the servlet.jar, of
course).  Put it in
the webapps/examples/WEB-INF/classes directory, and try to execute:

    http://localhost:8080/examples/servlet/TestDowncast

You will get back a 503 status because the servlet can't be loaded --
the root cause
is:

    java.lang.NoClassDefFoundError: org/apache/tomcat/HttpRequest

which happens because of the class loader restriction.

You can try to get around this by adding "package org.apache.tomcat" at
the top (and
moving to the appropriate classes subdirectory) and it still won't work
-- unless
you can add it to the system class path yourself.

(Consider it a first contribution to a test suite for Catalina :-).

>
> I prefer the proven Facade pattern to prevent downcasting.

Facades are a fine design pattern.  However, in this case, they would
require a lot
of cross-object method calls between the facade and the internal
representation,
which aren't necessary when they are one object that can reference
instance
variables directly.

>
> > * "Application" classes:  currently, the class loader looks
> >   in the application classpath first (WEB-INF/classes and
> >   WEB-INF/lib and then loads from the parent class loader
> >   if they are not found.  (See below for more about ordering).
>
> And of course you have a solution to deal with permissions ?
>

Not yet.  An implementation based on the Java2 permissions architecture
is required
before Catalina is ready to be proposed.

>
> > * The application class loader's parent is the
> >   system class loader as described above, without
> >   any access to the Tomcat internal classes (or the
> >   class loader that loaded them).
>
> Why would we need such thing? The Facade pattern used in
> tomcat's design can do exactly that in a clean and safe manner.
>
> Even more, you _can_ access tomcat internal classes on a controled
> manner ( using FacadeManager ), and it allows you to do a lot of
> lazy evaluations ( which will have a big impact in tomcat 3.3
> performance) ( that requires of course access to tomcat internals).
>

In the examples you gave for Nacho's question about lazy evaluation, I
don't see why
it makes any difference whether you're using Facades or not -- for
example Catalina
already implements your suggested lazy evaluation on the remote host
name.  The
request passed to the servlet (without facades) really is an internal
object, so it
already has access to the internals it needs.

Do you have some examples where using FacadeManager really makes a
performance
difference?

>
> Costin

Craig

Re: ClassLoaders

[cm...@yahoo.com]

> Catalina's application class loader (org.apache.tomcat.loader.FileClassLoader)
> distinguishes three kinds of classes.  The lists for the first two kinds are
> configurable (not yet from server.xml, but in the code) with defaults in
> square brackets.
> 
> * "Restricted" classes:  the class loader refuses to load
>   these classes at all  [org.apache.tomcat.*].  The intent
>   is to prevent a "bad guy" servlet from being able to cast
>   the HttpServletRequest and HttpServletResponse objects
>   passed to the service() method to their internal Tomcat
>   equivalents, and get into mischief.

:-)

So that's the magic way Catalina handles downcasting... Have you tested
this ? What VMs ? 

I prefer the proven Facade pattern to prevent downcasting.

> * "Application" classes:  currently, the class loader looks
>   in the application classpath first (WEB-INF/classes and
>   WEB-INF/lib and then loads from the parent class loader
>   if they are not found.  (See below for more about ordering).

And of course you have a solution to deal with permissions ?

> * The application class loader's parent is the
>   system class loader as described above, without
>   any access to the Tomcat internal classes (or the
>   class loader that loaded them).

Why would we need such thing? The Facade pattern used in 
tomcat's design can do exactly that in a clean and safe manner.

Even more, you _can_ access tomcat internal classes on a controled
manner ( using FacadeManager ), and it allows you to do a lot of
lazy evaluations ( which will have a big impact in tomcat 3.3
performance) ( that requires of course access to tomcat internals).

Costin

Re: ClassLoaders

["Craig R. McClanahan" <Cr...@eng.sun.com>]

cmanolache@yahoo.com wrote:

> Hi,
>
> I did some more reading ( and thinking ) about the class loader, and it
> seems the order is not enough.
>

You're right ... it's not.

>
> Probably what is needed is a JDK1.2-specific class loader ( where Package
> can be used ), and a way to also make sure that the webapp can't define
> classes in any package that is also defined by the system. ( sort of
> sealing - unfortunately only few pacakges use the "Sealed" and I'm not
> sure how this works in a multi-class loader env, i.e who have to enforce
> the sealed attribute)
>
> We'll end up with some more config, but I do want to implement context
> isolation and sandboxing, and probably I'll just start with a new
> classloader.
>

A couple of ideas (that are already implemented in the Catalina class loader)
are worth thinking about:

Catalina's application class loader (org.apache.tomcat.loader.FileClassLoader)
distinguishes three kinds of classes.  The lists for the first two kinds are
configurable (not yet from server.xml, but in the code) with defaults in
square brackets.

* "Restricted" classes:  the class loader refuses to load
  these classes at all  [org.apache.tomcat.*].  The intent
  is to prevent a "bad guy" servlet from being able to cast
  the HttpServletRequest and HttpServletResponse objects
  passed to the service() method to their internal Tomcat
  equivalents, and get into mischief.

* "System" classes:  the class loader passes these on to
  the parent class loader, without checking the local
  repositories like WEB-INF/classes and WEB-INF/lib.
  [java.*, javax.servlet.*].  Thus, you cannot try to impose
  your own version of java.lang.Object (although the normal
  Java security model probably protects you from this
  anyway -- paranoia can be quite useful).

* "Application" classes:  currently, the class loader looks
  in the application classpath first (WEB-INF/classes and
  WEB-INF/lib and then loads from the parent class loader
  if they are not found.  (See below for more about ordering).

The code currently doesn't use the "package" concept of Java2, but it can now
that we know about the Java2 dependency.

While this is all helpful, it's not clear yet whether bad guys can bypass the
restrictions we are trying to set up by asking for the parent class loader (or
the system class loader) directly, and asking *it* to load a class.
Therefore, it seems likely that we will want to arrange the internals of
Tomcat (of whatever flavor) a little differently to improve security:

* The Tomcat internal classes are moved out of
  $TOMCAT_HOME/lib, and are not added to the
  "system class path".  Same goes for whatever
  libraries Tomcat itself needs to function (such as
  the XML parser that it uses for server.xml and
  web.xml).

* The system class path consists of whatever is
  deployed in $TOMCAT_HOME/lib, perhaps plus
  the existing CLASSPATH, depending on what
  final choice we make on the startup scripts.

* The application class loader's parent is the
  system class loader as described above, without
  any access to the Tomcat internal classes (or the
  class loader that loaded them).

* The application class loader includes some sort
  of concept like restricted and system classes,
  similar to what is described above, that is configurable
  and has reasonable defaults.

All of this deals only with one particular type of attack -- trying to access
container internals or impersonate system classes.  There's lots of other
issues to deal with as well.


>
> Regarding ordering - I change my vote to -0, as long as you implement the
> different ordering in a configurable classloader that you can plug in
> instead of the default one, per context.
>

And the default should be the current order, for backwards compatibility.

>
> That mean I am ok with any class loaders that you use in a controled
> manner for your trusted ( or believed-to-be-trusted) applications. The
> plug in mechanism for that is not complete in 3.2, but it would be nice to
> have it in 3.3.

Going back to Costin's earlier question about confidence in our knowledge of
how class loading works -- I'll bet you get no takers on anyone claiming to be
an expert.  However, this whole thing illustrates one of the values of doing
this in an open source project -- we have to design things that work even
though attackers know everything about how our defenses are set up.  Relying
on any other approach (such as "security through obscurity") is pretty naive.

>
> ( Interesting reading: http://www.dyade.fr/fr/actions/VIP/JS_pap2.html
> )
>
> Costin
>

Craig

Re: ClassLoaders

[cm...@yahoo.com]

Also,

java.sun.com/security/SRM.html ( I know it is 1.0.2 - based ).

"Invariants

         System classes are found by using the Java-supplied
classLoader::findSystemClass method (and
         not by a home-grown method).

     ``System Classes'' are those classes found in the local file system
(constrained by CLASSPATH and
     other environmental controls). The loadClass method must acquire
these classes in the manner
     defined by the JDK. Failure to do so risks mapping of system class
names to code that doesn't properly
     implement the System Classes' specified behavior.
"

Costin

Re: ClassLoaders

[cm...@yahoo.com]

www.securingjava.com