Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 59143 invoked from network); 1 May 2005 10:20:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 May 2005 10:20:40 -0000 Received: (qmail 22705 invoked by uid 500); 1 May 2005 10:22:02 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 22672 invoked by uid 500); 1 May 2005 10:22:01 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 22656 invoked by uid 99); 1 May 2005 10:22:01 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of robertburrelldonkin@blueyonder.co.uk designates 195.188.213.9 as permitted sender) Received: from smtp-out6.blueyonder.co.uk (HELO smtp-out6.blueyonder.co.uk) (195.188.213.9) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 01 May 2005 03:22:01 -0700 Received: from knossos.elmet ([82.38.65.173]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sun, 1 May 2005 11:21:13 +0100 Subject: Re: [logging] tech.xml - child-first classloading not considered harmful From: robert burrell donkin To: commons-dev@jakarta.apache.org In-Reply-To: <1114772543.4400.44.camel@blackbox> References: <1114772543.4400.44.camel@blackbox> Content-Type: text/plain Date: Sun, 01 May 2005 11:28:16 +0100 Message-Id: <1114943296.5183.53.camel@knossos.elmet> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1-1mdk Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2005 10:21:13.0554 (UTC) FILETIME=[80797B20:01C54E37] X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Fri, 2005-04-29 at 23:02 +1200, Simon Kitching wrote: > Hi All, > > The following paragraph is from the "xdocs/tech.xml" document: > > > Parent-first loading has been the standard mechanism in the JDK > class loader, at least since Java 1.2 introduced hierarchical > classloaders. > > The primary reason for this is safety -- parent-first > makes it impossible for malicious code to trick the JVM into > replacing a core class (say, java.security.SecurityManager) > with a class of the same name loaded from a child classloader. > > > I believe this to be incorrect. I don't believe that such substitution > leads to any kind of security issue at all, and think this paragraph > should be removed from the document. > > Can anyone show any real security issues resulting from child-first > loading? i would suggest that the operative word here is real. it is very possible for sun to have chosen to recommend parent-first as the default for the reason given whilst at the same time the threat not being particularly credible in real life. a malicious classloader could perform all manner of nasty tricks. in this case, it doesn't really matter whether this classloader pretends to be parent or child first. not sure how credible a threat this is. not sure how an attacker could manage to insert a malicious classloader. (maybe other people with more knowledge would like to jump in here...) consider (instead) a badly written classloader. the threat to the system from a badly written parent-first classloader is much less than that from a badly written child-first classloader. bugs in the selection of which classes must be delegated (for security reasons) may allow malicious code to replace crucial security classes. whether this is a credible threat in real life is another matter. opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org