Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 15903 invoked from network); 4 Dec 2001 13:51:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Dec 2001 13:51:37 -0000 Received: (qmail 27822 invoked by uid 97); 4 Dec 2001 13:51:37 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 27806 invoked by uid 97); 4 Dec 2001 13:51:36 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 27795 invoked from network); 4 Dec 2001 13:51:36 -0000 Message-ID: <3C0CD550.7090606@apache.org> Date: Tue, 04 Dec 2001 08:53:20 -0500 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: [VOTE] ComponentValidator References: <3C0BF09C.1030107@apache.org> <200112040823.fB48NDu03582@mail012.syd.optusnet.com.au> <3C0CD24A.6060001@apache.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Berin Loritsch wrote: > Peter Donald wrote: > >> On Tue, 4 Dec 2001 08:37, Berin Loritsch wrote: >> >>> The ComponentValidator code has been fixed yet again. It's real home >>> belongs in Framework, and I propose to move it to Framework in the >>> following package: >>> >>> org.apache.avalon.framework.component.ComponentValidator >>> >>> This tool is used to verify the contracts of a Component's life >>> cycle. It >>> is invaluable for development. Do not vote in the negative if you just >>> want to be a PITA, or if you will not use it. Vote in the negative if >>> there is some stronger architectural or design issue at steak. >>> >> >> -1 >> It encourages bad practices - as exhibited by your dangerous fantasy >> that this will somehow make the application more secure. I want you to understand exactly the type of attack that this Component protects against with minimal overhead: BadComponent.compose( ComponentManager m ) { VulnerableComponent component = (VulnerableComponent) m.lookup( VulnerableComponent.ROLE ); if (component instanceof Composable) { Composable composable = (Composable) component; composable.compose( m_evilComponentManager ); } } As you can see, a vulnerable component will not make any rudimentary checks to see if it has already been Composed, or if it has been hijacked during initialization. Therefore, it will allow this: VulnerableComponent.compose( ComponentManager m ) { m_manager = m; m_criticalComponent = (CriticalComponent) m_manager.lookup( CriticalComponent.ROLE ); } Thus overwriting the reference to the critical component. All future uses of that component will be sent to BadComponent's m_evilComponentManager. For components that lookup what they need as they use it, it has the same effect. Validating lifecycle is absolutely critical in an environment where Components are pluggable and dynamically loaded. Should it replace other basic tenets of security like never loading a Component you don't know? Never. However, such an approach *minimizes* the number of things a maliscious Component can do if it somehow gets itself loaded in the environment. It is very much analogous to UNIX file permissions in that they are not in and of themselves security, however they help to minimize damage once security is breached. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin -- To unsubscribe, e-mail: For additional commands, e-mail: