Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Message-Id: <200112051025.fB5AP6O10124@mail016.syd.optusnet.com.au>
Content-Type: text/plain;
  charset="utf-8"
From: Peter Donald <peter@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: Re: [VOTE] ComponentValidator
Date: Wed, 5 Dec 2001 18:56:32 +1100
References: <3C0BF09C.1030107@apache.org> <3C0CD24A.6060001@apache.org>
 <3C0CD550.7090606@apache.org>
In-Reply-To: <3C0CD550.7090606@apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Wed, 5 Dec 2001 00:53, Berin Loritsch wrote:
> 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:

I am quite aware of your opinion which is exactly why I used the term 
"dangerous fantasy".

> 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.

Lets go with your UNIX file permissions analogy. 

* Containers in Avalon are analogous to the kernel
* Components are analogous to processes

One a kernel is breached it matters little what UNIX file permissions are 
assigned to a particular user/group because they can just change users or 
grab what ever perms they feel like. I could translate into java terms but 
you get the idea.

Continuing on with the analogy, you are trying to protect applications in the 
case where the kernel does not implement proper isolation. Lets say there is 
no such thing as memory protection between applications - anyone who has 
written code in an environment like that knows there is very little you can 
do to protect your app in a sitation like that where an "evil" application 
decides to mess with your app.

-- 
Cheers,

Pete

*-------------------------------------*
| Does the name `Pavlov' ring a bell? |
*-------------------------------------*


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>