Re: New Java Security Flaw Found

[dichro-7f3e596 () ERIS RCPT TO (Mikolaj J. Habryn)]

> > > > > "SG" == Sean Garagan <garagan () BORG CS DAL CA> writes:

    SG> I was actually quite surprised to see this when I wrote a
    SG> ClassLoader a while ago.  I had wrongly assumed Sun would hard
    SG> code checks for the core Java classes.  It looks like Sun
    SG> relies on proper security implementations to prevent the
    SG> ClassLoader from being replaced.

  Forcing java.lang.* to go through the system ClassLoader would be
somewhat unfortunate in somce cases. There are circumstances
(specifically in environments where you are handling potentially
hostile foreign code) where you will want to either totally refuse
access to some classes (java.lang.reflect leaps to mind), or redefine
them (make methods final, or potentially remove some methods
altogether). Yes - you're violating bits of the specification, but
sometimes information leaks are things you really don't want.

  To reiterate, not protecting java.lang.* is *not*, IMHO, a
bug. ClassLoaders are dangerous things, and you want to be very
careful about who gets to play with them. And ClassLoader isn't the
only class worth having a good, long look at. If you're trying to
maintain the integrity of separate protection domains, all running
foreign code but interacting in a single VM, then java.lang.Object is
where you start worrying.

m.