> 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. Mike Colbert --- robert burrell donkin <[EMAIL PROTECTED]> wrote: > On Tue, 2005-05-03 at 19:16 +0200, Ceki G�lc� wrote: > > Parent-last! Nice, simple and so much more accurate than child-first, the > > term everyone, including myself, uses but which is also unfortunately > > incorrect. > > actually, mike's right. (took me a while to get my head round it 8-) > > > > > As for the lack of security of parent-last class loaders, since a class > > loader can load classes as it wants in the order it wamts, it's hard to see > > > how the delegation order matters in the case of a malicious class loader. > > i agree that delegation order does not matter in the case of a malicious > classloader. delegation order does matter in the case of a bad written > classloader faced with malicious code. > > for example, consider a malicious web application deployed on an ISP's > container together with a top secret application. suppose that the > classloader used by the container is badly coded and contains bugs. > > the attempted attack would be to use a SecurityManager implementation > contained in the malicious web application to bypass the security > provided by the ISP to prevent information being read from the secret > application. > > 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. > > bit far fetched, i hope you agree. however, bear in mind that i never > claimed real life security advantages, just that sun felt there may be > some theoretic ones. > > - robert > > > At 16:58 5/3/2005, Mike Colbert wrote: > > > > >This sounds reasonable to me. It would be nice to have something > definitive, > > >however. I think it's an interesting topic and I've be following it on > this > > >list. So far, all the security risks Simon has referenced (and > questioned) > > >don't seem to go much beyond hand-waving so I agree with him they are > > >dubious. > > >A test case demonstrating some of these alleged security risks would be > > >helpful; I can't put my head around them without more detail and context. > > >Could be that these risks only affect 1% or real-world apps under a > specific > > >scenario. Even if it's 0.01% or entirely theoretical, a test case would > be > > >useful to even understand what the risk really is supposed to be. > > > > > >As an aside, isn't "child-first" really a misnomer and it's more like > > >"parent-last"? Assuming the parent is at the top of the hierarchy, > > >child-first > > >implies (to me), that the heirarchy is walked downwardly from the parent, > not > > >upwardly from the bottom. > > > > > >Mike Colbert > > > > --------------------------------------------------------------------- > 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]
