If a security manager was in place to begin with, which it would be in an environment which you would want to secure, it probably wouldn't allow applications to create their own classloaders anyway (the ClassLoader class' constructor checks to see whether you have that privilege). A reasonable SecurityManager wouldn't allow itself to be replaced, so a "malicious" one wouldn't be able to let an application "break out of its sandbox." If there isn't a SecurityManager installed, there IS no sandbox.
-----Original Message----- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 4:39 PM To: Jakarta Commons Developers List Subject: Re: [logging] tech.xml - child-first classloading not consideredharmful On Wed, 2005-05-04 at 13:03 -0700, Mike Colbert wrote: > > in the case of a parent-first classloader, the buggy implementation > > would not be exposed since the call would be delegated to the system > > classloader. in the case of a child-first classloader, a buggy > > implementation may try to define SecurityManager itself and this bug > > exploited. > > This would mean an attacker would have to take advantage of a bug in a > class loader which allows them to load a malicious SecurityManager in > such a way that it would be shared by all applications. I can kind of > see how parent-first delegation would mitigate this, but one would > think that with appropriate levels of class loader isolation in place > the delegation order becomes a non-issue. Maybe the bug has something > to do with broken isolation. i was thinking that a malicious SecurityManager implementation might allow an application to break out of it's sandbox but i'm not an expert and this is really just speculation on my part. i don't think that this kind of attack is any sort of realistic threat. this would be a good time for craig to jump in... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
