You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/12/03 22:37:32 UTC
[VOTE] ComponentValidator
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.
We have been going back and forth over this, and it is rediculous. Most development
houses will welcome such a utility, and it is very useful.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Peter Donald <pe...@apache.org>.
On Thu, 6 Dec 2001 15:22, Peter Donald wrote:
> > Again, the most useful aspect of the ComponentValidator (IMO) is the
> > checkActive() function. ComponentValidator.checkActive() and it's cousin
> > ComponentValidator.isActive() are used to make sure that the Component is
> > not used _before_ it's container is finished initializing it or _after_
> > it's container has disposed of it.
>
> Again - this is something that should be done in the container. Phoenixs
> proxys are not made accessible before the component is ready to accept
> requests and just before the component is about to be shutdown the proxy
> will be invalidated.
>
> Anyone calling a method after invalidation will get an
> IllegalStateException thrown that saids "you are using a service after it
> has shutdown - naughty, very naughty!"
>
> Again this way the component never has to worry about it and it is up to
> the conainer to validate and maintain correct lifecycle management and you
> aren't mixing concerns.
The only thing the component needs to worry about is making sure that its
work interface is correctly guarded and I have no problem with that.
--
Cheers,
Pete
------------------------------------------
I just hate 'yes' men, don't you Smithers?
------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Thu, 6 Dec 2001 09:30, Berin Loritsch wrote:
>
>>A new issue:
>>
>>Components that will be "marketed", "sold", or otherwise be made available
>>for general consumption _without_ a supplied Container need to validate
>>that their lifecycle is called correctly. Such components cannot make the
>>assumption that the users of that Component have properly read the
>>documentation for Avalon, and need to fail fast if it is not called
>>correctly. Remember that Components can be Containers as well. Not
>>everyone gets it right the first time.
>>
>
> All components are built for a container. It makes no sense otherwise.
:)
Of course Components are built for a container. It doesn't mean that someone
providing a library is going to create a Container for them and include that
Container in the library. All it means is that people who don't RTFM are going
to mess up with creating the Container if they are not familiar with Avalon.
>>>Unix security permissions are not the most fine grained in the world. It
>>>is far easier to create a more secure environment as we can give fine
>>>grain access and control over resources or even make resources
>>>unreferencable by using code (except if they go JNI which a sandboxed
>>>environment would not allow).
>>>
>>No they aren't, and neither are lifecycle assertions.
>>
>
> No idea what you are referring to ;)
"Unix security permissions are not the most fine grained in the world."
>>Assertions and FilePermissions both exist to keep you from shooting
>>yourself in the foot.
>>
>
> File permissions aye ?
Yes. The famous "rm -rf /" will only erase files that _you_ have write
permissions to. You may lose all your data, but you won't lose your
system (unless the sysadmin is on crack).
>>They _also_ provide immediate feedback if you just
>>messed up your container.
>>
>
> This is why we should have unit tests to validate container behaviour. This
> catches problems before any component is ever deployed into the container.
That is something we will provide in Excalibur--because the ExcaliburTestCase
provides all the extra stuff we need.
>>Again, the most useful aspect of the ComponentValidator (IMO) is the
>>checkActive() function. ComponentValidator.checkActive() and it's cousin
>>ComponentValidator.isActive() are used to make sure that the Component is
>>not used _before_ it's container is finished initializing it or _after_
>>it's container has disposed of it.
>>
>
> Again - this is something that should be done in the container. Phoenixs
> proxys are not made accessible before the component is ready to accept
> requests and just before the component is about to be shutdown the proxy will
> be invalidated.
What about the rest of us? Not everyone is using Phoenix's proxies. Not
everyone is using Pheonix. Are we going to have to beef up the
DefaultComponentManager in Avalon Framework to demonstrate what _should_
be done? In essense, it should be a model of how to create a ComponentManager.
> Anyone calling a method after invalidation will get an IllegalStateException
> thrown that saids "you are using a service after it has shutdown - naughty,
> very naughty!"
>
> Again this way the component never has to worry about it and it is up to the
> conainer to validate and maintain correct lifecycle management and you aren't
> mixing concerns.
I'm beginning to see where you are going. And I might be inclined to agree
with you. The only problem is that we don't have any way of enforcing these
things now.
Beyond that, due to all the secure installations I have had to deal with, I
am beginning to err on the side of paranoia. "Explicitly don't allow anything
that isn't supposed to happen." Honestly, I don't trust all containers. I
don't even trust me to do it right all the time--much less you or anyone else.
Mistakes happen--its a fact of life. That is why there are such things as
bugs.
>>BTW, I have no false sense of security. Perhaps using something like that
>>will make you fall into such a trap--but it is a tool combined with tons of
>>other tools that help in the overall goal.
>>
>
> Why am I reminded of the Princess Bride at this point? "You keep using the
> word ... "
Great movie!
" ... 'inconceivable'. I don' think it means what you think it means."
Maybe I should change my signature?
"Alo'! My name is Inego Montoya, you killed my father. Prepare to die."
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Peter Donald <pe...@apache.org>.
On Thu, 6 Dec 2001 09:30, Berin Loritsch wrote:
> A new issue:
>
> Components that will be "marketed", "sold", or otherwise be made available
> for general consumption _without_ a supplied Container need to validate
> that their lifecycle is called correctly. Such components cannot make the
> assumption that the users of that Component have properly read the
> documentation for Avalon, and need to fail fast if it is not called
> correctly. Remember that Components can be Containers as well. Not
> everyone gets it right the first time.
All components are built for a container. It makes no sense otherwise.
> > Unix security permissions are not the most fine grained in the world. It
> > is far easier to create a more secure environment as we can give fine
> > grain access and control over resources or even make resources
> > unreferencable by using code (except if they go JNI which a sandboxed
> > environment would not allow).
>
> No they aren't, and neither are lifecycle assertions.
No idea what you are referring to ;)
> Assertions and FilePermissions both exist to keep you from shooting
> yourself in the foot.
File permissions aye ?
> They _also_ provide immediate feedback if you just
> messed up your container.
This is why we should have unit tests to validate container behaviour. This
catches problems before any component is ever deployed into the container.
> Again, the most useful aspect of the ComponentValidator (IMO) is the
> checkActive() function. ComponentValidator.checkActive() and it's cousin
> ComponentValidator.isActive() are used to make sure that the Component is
> not used _before_ it's container is finished initializing it or _after_
> it's container has disposed of it.
Again - this is something that should be done in the container. Phoenixs
proxys are not made accessible before the component is ready to accept
requests and just before the component is about to be shutdown the proxy will
be invalidated.
Anyone calling a method after invalidation will get an IllegalStateException
thrown that saids "you are using a service after it has shutdown - naughty,
very naughty!"
Again this way the component never has to worry about it and it is up to the
conainer to validate and maintain correct lifecycle management and you aren't
mixing concerns.
> BTW, I have no false sense of security. Perhaps using something like that
> will make you fall into such a trap--but it is a tool combined with tons of
> other tools that help in the overall goal.
Why am I reminded of the Princess Bride at this point? "You keep using the
word ... "
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Thu, 6 Dec 2001 01:34, Berin Loritsch wrote:
>
>>The main issue is forcing correctness. Since we are not creating JDK 1.4
>>compliant code right now, we can't take advantage of Assertions. You seem
>>to be in favor of assertions,
>>
>
> I am in favour of using assertions when there is potential for bad
> interactions to occur. So if you were asking to make it validate Component ->
> Component comms (via Work interface) then +1. However what you are asking to
> validate is Container -> Component comms (via lifecycle interface). I don't
> think this should ever ever ever be required as if it is required then there
> is something fundamentally wrong with your architecture. I do not put checks
> in my servlets to validate that init() isn't called twice and think it is bad
> programming to do so.
Perhaps, but examine the following scenario (a real one as I advised against it
on Cocoon's list):
The Sitemap allows you to declare components that can be loaded in at run-time,
Another thing that Sitemap allows you to do is to mount sub-sitemaps at any
file location on the server. Something like this is feasible:
<map:match pattern="~/*/**">
<map:mount uri="{1}" location="/home/{1}/cocoon/"/>
</map:match>
That means any of the client users can declare their own components to be
included in their environment. This can be potentially dangerous for a number
of reasons (all the same reasons that UNIX servers can get hacked). However,
the core Components should provide the assertions to protect itself.
Should the Sitemap's ComponentManager sandbox it's components? Sure. I don't
deny it. Can it be done? Yes. I spent alot of time to make Sitemap Component
Manager's heirarchical. This also led to some hacks of the ComponentSelector,
but in the end it is able to be sandboxed.
Should we look into redoing ExcaliburComponentManager to taking advantage of
the Dynamic Proxy code--probably. There is a lot of things I want to do with
it.
Does this negate the addition of ComponentValidator? No. Again, server side
components (more than client side components) need to verify all their contracts
on both sides. It wouldn't be _as_ big an issue if any of the supplied Containers
provided the "sandbox" environment. Still, most engineers will consider it
*good* programming style to validate your contracts. Even the lifecycle ones.
Some would say *especially* the lifcycle ones. Engineers tend to be cynical
at best.
> However far worse than this is the fact that you believe that it will make
> your apps more "secure". (I know you specify this in your docs but I disagree
> with this - I also disagree that Avalon is aimed at the serverside aswell ;]).
Re: serverside
I never got around to changing the wording--mostly because I haven't come up
with anything I liked.
Re: secure
As I keep reiterating, security is a multifaceted problem. In order to declare
a Component as Secure, you have to verify _all_ it's contracts, you have to verify
the Container, you have to do a great many things. As I warned that IoC is not
equivalent to security, contract validation is not either. I never argued this
point. I merely argued that it is a *tool* to be used in the quest towards a
secure server.
A new issue:
Components that will be "marketed", "sold", or otherwise be made available for
general consumption _without_ a supplied Container need to validate that their
lifecycle is called correctly. Such components cannot make the assumption that
the users of that Component have properly read the documentation for Avalon,
and need to fail fast if it is not called correctly. Remember that Components
can be Containers as well. Not everyone gets it right the first time.
>>I am not arguing that point. However, it is more difficult to get 'root'
>>access than breach a specific program. The practice of running web
>>services (like the HTTP server) as a user is so that if the program/service
>>is compromized, the attacker has the permissions of that service. For
>>instance, if Apache was running as 'nobody', and someone managed to crack
>>it, and get access to the machine through that service, they would have the
>>priveleges of the 'nobody' user. Running the http esrver as 'root' is like
>>asking a hacker to take control of your machine because you are
>>masochistic.
>>
>
> Unix security permissions are not the most fine grained in the world. It is
> far easier to create a more secure environment as we can give fine grain
> access and control over resources or even make resources unreferencable by
> using code (except if they go JNI which a sandboxed environment would not
> allow).
No they aren't, and neither are lifecycle assertions.
> Running everything as nobody (even chrooted) is not a great idea as far as I
> can see. One of my friends showed me how you could compromise one "nobody"
> service, then attach debuggers to other "nobody" services and voila you
> control the machine (it may not give you root directly but it gives you
> access to all services running on machine). Maybe this style attack is linux
> specific though ...
Not everything get run as "nobody". In fact, on most current installs just about
all the services run as their own user. But this is getting off the original
point.
Assertions and FilePermissions both exist to keep you from shooting yourself
in the foot. They _also_ provide immediate feedback if you just messed up
your container.
Again, the most useful aspect of the ComponentValidator (IMO) is the checkActive()
function. ComponentValidator.checkActive() and it's cousin ComponentValidator.isActive()
are used to make sure that the Component is not used _before_ it's container is
finished initializing it or _after_ it's container has disposed of it.
Example:
class MyComponentImpl implements Component, MyComponent
{
ComponentValidator m_validator;
void doSomething()
{
m_validator.checkActive();
}
}
This check cannot accurately pass without performing the other validations.
Also, keep in mind that the Container can also perform the validations externally
to the Component whether it uses the ComponentValidator or not.
>>But let me bring in one more valid point. We have the pattern of Inversion
>>of Control and its antipattern Subversion of Control. The
>>ComponentValidator makes it more difficult to subvert the control of a
>>Component. It's not impossible, but it is more difficult. It encourages
>>proper use of a Component.
>>
>
> It doesn't make it more difficul tit just means the attacker has to use
> alternative methods. Worse it gives a false sense of security when there is
> none.
Meaning that it performed the function that it was supposed to perform.
Eventually I have to come up with an extensive security document--but who
has the time? That would allow me to elaborate on all the issues.
BTW, I have no false sense of security. Perhaps using something like that
will make you fall into such a trap--but it is a tool combined with tons of
other tools that help in the overall goal.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Peter Donald <pe...@apache.org>.
On Thu, 6 Dec 2001 01:34, Berin Loritsch wrote:
> The main issue is forcing correctness. Since we are not creating JDK 1.4
> compliant code right now, we can't take advantage of Assertions. You seem
> to be in favor of assertions,
I am in favour of using assertions when there is potential for bad
interactions to occur. So if you were asking to make it validate Component ->
Component comms (via Work interface) then +1. However what you are asking to
validate is Container -> Component comms (via lifecycle interface). I don't
think this should ever ever ever be required as if it is required then there
is something fundamentally wrong with your architecture. I do not put checks
in my servlets to validate that init() isn't called twice and think it is bad
programming to do so.
However far worse than this is the fact that you believe that it will make
your apps more "secure". (I know you specify this in your docs but I disagree
with this - I also disagree that Avalon is aimed at the serverside aswell ;]).
> however you are against this validator that
> provides some very specific assertions with minimal overhead. The thing
> is, explicit casting is expensive in Java. The JVM needs to get a handle
> on the Class, look up the interfaces/classes that are implemented/extended,
> and then determine if it is possible to perform the cast.
Actually you would be surprised how little it costs now. I know IBMs JVM
performs some optimizations that allow casts to be a couple of bitwise
ANDs/comparisons. Suns JVM don't use that optimization yet (uses too much
memory) but in JDK1.4 I believe the class instanceof style comparisons will
be considerably faster.
Besides speed was never why I objected. I prefer correctness over speed in
90% of cases and even if the cost was multiplied by 100 I doubt it would have
a significant effect on any applications I write (because it is mostly done
at init time).
> I am not arguing that point. However, it is more difficult to get 'root'
> access than breach a specific program. The practice of running web
> services (like the HTTP server) as a user is so that if the program/service
> is compromized, the attacker has the permissions of that service. For
> instance, if Apache was running as 'nobody', and someone managed to crack
> it, and get access to the machine through that service, they would have the
> priveleges of the 'nobody' user. Running the http esrver as 'root' is like
> asking a hacker to take control of your machine because you are
> masochistic.
Unix security permissions are not the most fine grained in the world. It is
far easier to create a more secure environment as we can give fine grain
access and control over resources or even make resources unreferencable by
using code (except if they go JNI which a sandboxed environment would not
allow).
Running everything as nobody (even chrooted) is not a great idea as far as I
can see. One of my friends showed me how you could compromise one "nobody"
service, then attach debuggers to other "nobody" services and voila you
control the machine (it may not give you root directly but it gives you
access to all services running on machine). Maybe this style attack is linux
specific though ...
> Let me ask you, is it the Container's responsibility to detect when a
> Component is obtained
yes. One of my TODOs for phoenix is to detect when it is not obtained (but
declared as a dependency and issue warnings.
> and cast as a Composable?
impossible to detect this but it can block it being cast to something it
shouldn't be cast to.
> Implementing such a beast
> is pretty complex,
Almost 7 lines of code !
> and more than likely, the cost of proxying the Component
> outweighs it's usefullness.
perhaps.
> But let me bring in one more valid point. We have the pattern of Inversion
> of Control and its antipattern Subversion of Control. The
> ComponentValidator makes it more difficult to subvert the control of a
> Component. It's not impossible, but it is more difficult. It encourages
> proper use of a Component.
It doesn't make it more difficul tit just means the attacker has to use
alternative methods. Worse it gives a false sense of security when there is
none.
--
Cheers,
Pete
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> 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".
We all know there are different levels of protection. However, there are
more reasons than just protecting against the attack I displayed in my
previous message. I will address the levels below on your discussion of
UNIX file permissions.
The main issue is forcing correctness. Since we are not creating JDK 1.4
compliant code right now, we can't take advantage of Assertions. You seem
to be in favor of assertions, however you are against this validator that
provides some very specific assertions with minimal overhead. The thing
is, explicit casting is expensive in Java. The JVM needs to get a handle
on the Class, look up the interfaces/classes that are implemented/extended,
and then determine if it is possible to perform the cast. If we use
assertions, we would be spreading the cost of that lookup to every invokation
of the lifecycle methods.
Taking this one step further, so that _when_ we do directly support assertions,
we can minimize the cost of keeping them on. For instance, the following
snippet (scope omitted for clarity):
class MyComponent implements Component, Composable
{
ComponentValidator m_validator;
ComponentManager m_manager;
MyComponent()
{
assert m_validator = new ComponentValidator(this);
}
void compose( ComponentManager manager )
{
assert m_validator.checkAssigned(m_manager);
assert m_validator.checkComposed();
m_manager = manager;
}
}
There, the existence of the validator is only there when assertions are enabled.
That way, when assertions are turned off, the Validator and it's checks are
not performed. This also are well behaved assertions in that there are no
side-effects to require them to be turned on.
Also, the existence of the ComponentValidator allows engineers (since they will
insist on performing these validations) to implement their checks correctly--
without reinventing the same wheel in several Components.
During the interim where assertions are _not_ supported yet, these provide an
almost invisible way of performing the assertions in a run-time system. They
are about as costly as using LogKit with the logger.isXXXenabled() methods.
We might want to add validator.isComposed(), etc. methods to the class so that
assertions are more correct (they test booleans).
For instance, this would be correct:
assert m_validatory.isAssigned(m_manager);
assert m_validator.isComposed();
While the .checkXXX() methods are necessary in the absence of assertions.
>>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
They are more analogous to programs. I will elaborate a little more later.
> * 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
I am not arguing that point. However, it is more difficult to get 'root'
access than breach a specific program. The practice of running web services
(like the HTTP server) as a user is so that if the program/service is
compromized, the attacker has the permissions of that service. For instance,
if Apache was running as 'nobody', and someone managed to crack it, and get
access to the machine through that service, they would have the priveleges of
the 'nobody' user. Running the http esrver as 'root' is like asking a hacker
to take control of your machine because you are masochistic.
There are ways of gaining root access at this point, however it is not as easy
as doing it when the server is running as root. Also, as Leo pointed out, the
File Permissions are to protect users from themselves more than they are to
protect against hackers. For instance, just because someone can type in the
infamous command `rm -rf /` does not mean that the system should allow the
user to wipe out any files they are not supposed to.
> 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.
Let me ask you, is it the Container's responsibility to detect when a Component
is obtained and cast as a Composable? Implementing such a beast is pretty
complex, and more than likely, the cost of proxying the Component outweighs
it's usefullness. For Blocks, it is a different story. They require that
extra level of security.
But let me bring in one more valid point. We have the pattern of Inversion
of Control and its antipattern Subversion of Control. The ComponentValidator
makes it more difficult to subvert the control of a Component. It's not
impossible, but it is more difficult. It encourages proper use of a Component.
Checks should not _only_ be performed on the server side (of a client/server
application or in this case container/component), but _ideally_ on the client
side as well.
The FullLifeCycle Component used to test the ComponentValidator is the perfect
tool to *also* test proper Containers. It will throw an exception if the
initialization is not in the proper order. While it would *technically* be
possible to do the same thing without the ComponentValidator, the Validator
is a good tool to provide assertions at low cost while there are no language
features available.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>damn - we got to start some flaming then ;) We used have fun ones back in the
>old days ;)
>
-1 for flaming.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 5 Dec 2001 04:40, Leo Sutic wrote:
>
>>>This is one of my points, unfortunately Peter *will* not hear it.
>>>
>>Maybe so. Given that this is as close to a flame fest that I've seen on
>>avalon-dev, I'd rather wait for Peter's response or non-response.
>>
>
> damn - we got to start some flaming then ;) We used have fun ones back in the
> old days ;)
I don't think people remember that far back :)
Remember the discussions on JNDI vs. ComponentManager?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Peter Donald <pe...@apache.org>.
On Wed, 5 Dec 2001 04:40, Leo Sutic wrote:
> > This is one of my points, unfortunately Peter *will* not hear it.
>
> Maybe so. Given that this is as close to a flame fest that I've seen on
> avalon-dev, I'd rather wait for Peter's response or non-response.
damn - we got to start some flaming then ;) We used have fun ones back in the
old days ;)
--
Cheers,
Pete
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] ComponentValidator
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> I never argued against a testcase for containers.
I'm not saying you did. It is obvious that a testcase and ComponentValidator are not mutually exclusive and I do not know of anyone who have tried to frame it that way.
My basic idea was to argue from the statement that contracts must be validated, and then show how a ComponentValidator complements the test case Peter saw as a solution.
> This is one of my points, unfortunately Peter *will* not hear it.
Maybe so. Given that this is as close to a flame fest that I've seen on avalon-dev, I'd rather wait for Peter's response or non-response.
> Can I assume then that your are +1 on the matter?
I am not a committer.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Berin, Peter,
>
> I'm not very worried about the security aspects of the ComponentValidator class. Like Peter, I see the battle as lost when a malicious component has entered the system, and I do not see that as enough reason to increase code complexity.
>
This is true, but you can still minimize damage.
> However, I am much more concerned with buggy containers. The case could be made that a test case for containers would solve this, and I think Peter is completely right in that. Such a test case *is* needed. There's no argument against it.
>
I never argued against a testcase for containers. I argued *for* inclusion of ComponentValidator
> But it is also considered good practice to add assertions throughout the code, to catch things that "can not" happen, and I see the ComponentValidator as a tool for that.
>
This is one of my points, unfortunately Peter *will* not hear it.
> Assertions provide a nice fail-fast, and aids in debugging.
>
> (Regarding UNIX file permissions: I see the security aspect of them, but to me they are also protection against users inadvertently deleting the wrong files. I have had much more work related to user screwups than cracker assaults. The neat thing is that I get protection from both from file permissions. ComponentValidator does the same - primarily I get faster debugging and better regression tests, and if it stops some component hell-bent on destruction as well, then that is good.)
>
Yet another point in favor of the ComponentValidator.
Can I assume then that your are +1 on the matter?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] ComponentValidator
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Berin, Peter,
I'm not very worried about the security aspects of the ComponentValidator class. Like Peter, I see the battle as lost when a malicious component has entered the system, and I do not see that as enough reason to increase code complexity.
However, I am much more concerned with buggy containers. The case could be made that a test case for containers would solve this, and I think Peter is completely right in that. Such a test case *is* needed. There's no argument against it.
But it is also considered good practice to add assertions throughout the code, to catch things that "can not" happen, and I see the ComponentValidator as a tool for that.
Assertions provide a nice fail-fast, and aids in debugging.
(Regarding UNIX file permissions: I see the security aspect of them, but to me they are also protection against users inadvertently deleting the wrong files. I have had much more work related to user screwups than cracker assaults. The neat thing is that I get protection from both from file permissions. ComponentValidator does the same - primarily I get faster debugging and better regression tests, and if it stops some component hell-bent on destruction as well, then that is good.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Berin Loritsch <bl...@apache.org>.
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 don't see how validating lifecycle is concidered bad practice! That statement
makes absolutely 0 sense. As does the statement that it _inherently_ makes
more secure. Security is a big subject covering many different aspects. Just
as IoC !~ (read 'not equivalent') security, neither does this. HOWEVER, it
is a tool used to reach security.
> Verifying the lifecycle stages is a responsability of the container writer.
> If you want to write a tool that makes it easy for the container writer to
> write tests then go for it. Making sure the container is operational is not
> the component writers responsibility.
I disagree with you again on this point. Any mission critical component must
verify it's contracts and enforce them. Beyond that, it is the Component writer's
responsibility to ensure that their component is used in an authorized fashion.
Out of order lifecycles are not authorized use. Robbing someone of that tool
is ludicrous.
> So far I haven't seen any argument that I would call legitimate for even
> using it - let alone encouraging its wide use. If you really want it in
> framework then feel free to chuck it in a proposal directory on the condition
> that it doesn't appear in source or binary form in the upcomming release.
> Maybe you can convince me after release (using logic).
As I have not seen any argument against that I would call legitimate for *not*
using it. I would highly recommend enforcing lifecycle control. I even condone
it in the Developing with Avalon paper. As to convincing you with logic, on this
point I don't know if it is possible. You won't hear logic.
> Besides I am a PITA and I won't use it ;)
Ah, the real reason comes out ;)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] ComponentValidator
Posted by Peter Donald <pe...@apache.org>.
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.
Verifying the lifecycle stages is a responsability of the container writer.
If you want to write a tool that makes it easy for the container writer to
write tests then go for it. Making sure the container is operational is not
the component writers responsibility.
So far I haven't seen any argument that I would call legitimate for even
using it - let alone encouraging its wide use. If you really want it in
framework then feel free to chuck it in a proposal directory on the condition
that it doesn't appear in source or binary form in the upcomming release.
Maybe you can convince me after release (using logic).
Besides I am a PITA and I won't use it ;)
--
Cheers,
Pete
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>