www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: WORA Considered Evil ;-)
Date Fri, 27 Jun 2003 22:37:04 GMT

I'm sure that everyone is in favour of hardening James as much as possible.
Its just that we should approach it from a Java perspective, not a C on Unix
one. The issues are different.

> Frankly, I don't want to run anything at root that can avoid
> it.  That is
> just good practice.

Sure, and you don't have to. Hey, we routinely run BEA WebLogic in
distributed cluster of 20 big Sun/Solaris servers under ids. with just the
required privileges rather than root and just the one JVM per machine, no
problem. There are much larger similar configurations around. There is a big
J2EE app. server base out there that has had to face these issues and
resolve them. They have, so we can.

> Consider Vincenzo's anti-spam matcher.  Would you want that
> to run as root?

No, and there is no need to as explained above. Then I wouldn't want it to
run with the same privileges as James or a James component either. It would
be good to be able to define the launch environment for an executable, which
is where most of the vulnerabilities occur. To be fair, I believe that
Vincenzo has only looked at this from the Win32 perspective and doesn't have
the options available on a Unix platform.

> > There is no need to distribute James' components over
> multiple JVMs to
> > enhance security or robustness.
> I disagree as a technical matter.

Such as? I can tell you in advance that my response will be that if a
problem exists it should be fixed at source so that it works within a single
JVM and then scales. Otherwise we are temporarily circumventing the problem
and someday we will hit it again in a distributed solution and ultimately
will have to fix it much more expensively. Been there.

> I can give you plenty of good reasons for why you want the
> ability to run
> the mailet pipeline at privileges other than root:

I think we are agreed that we don't want to run at root and hopefully I have
shown that you don't need to. But the following is really useful in
explaining why we don't want to and what we might want to distribute for
performance reasons.
>  - the chance of a JVM exploit.
>  - potential exploits via native code in
>    a JDBC driver.
>  - the use of native code in matchers/mailets,
>    e.g., the anti-virus matcher.
>    ---------------------------------------------------
>  - the use of third party matchers/mailets.
>  - the use of user-defined scripting matchers/mailets
>  - support for SOAP
>  - one pipeline being extra busy or big
>    performing lots of processing and/or
>    handling large messages, should not
>    deny service to other users.
I remain unconvinced that all of the issues are potential security risks,
but as I tried to say in an earlier posting, its a matter of trust. We
should certainly make James sufficiently configurable that it can be
integrated into trusted practises wherever feasible, whether that trust is
well placed or not. Conversely, James should be immune as possible from
vulnerabilities exposed by malconfiguration.

> Next, consider the dynamic reconfiguration issue, which
> thread I have no had
> time to respond to over the past couple of days....

Noel, I'll respond to this in the Dynamic Reconfiguration thread, but in
short we're in agreement, you are echoing my thoughts here.

-- Steve

To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message