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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
