avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] ComponentValidator
Date Wed, 05 Dec 2001 22:30:05 GMT
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/"/>

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

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

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.


class MyComponentImpl implements Component, MyComponent
     ComponentValidator m_validator;

     void doSomething()

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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message