james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject Hardening James - Security, Reliability and Scalability
Date Wed, 09 Jul 2003 10:49:20 GMT

You may have seen some of the following discussed in the thread "WORA
Considered Evil  ;-)". This was being forwarded to community@apache.org and
pier@apache.org. As Noel suggested I'm restarting this as an internal James
developer discussion. There are a number of issues that influence the
direction James could take that span out of the previous thread and are
worth examining.

I hope the following is a fair summary of the technical issues raised. I
have tried to highlight the issues rather than provide answers, except where
a consensus view seems to have emerged.

1) Should James run as "root" on Un*x-like OSes?

Running services as "root" is generally undesirable. The only reason for
running James as "root" is to access ports under 1024. As hardware/software
firewalls or a simple proxy can remap these to port numbers 1024 and above,
there is no need to run James as "root". Noel has posted example iptables
entries for Linux, similair facilities exist in most Un*xes.

2) Should the various James components such as SMTP server, Mailet Engine,
POP3 server, News server, etc., be run in separate VMs in order to enhance

No majority view on if this is merited from a security aspect. But as it is
technically possible, with perhaps a few changes, there is a something
resembling a consensus which says "If it engenders trust amongst sysadms who
are used to doing things this way, why not?"

3) During the discussion Noel said...

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

The "root" issue is answered in (1) above, but the reasons are just as valid
whatever privileges as "james" runs at.

> - 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.
>None of the items below the bar are related to native code exploits.  A
>single JVM is not secure when you start taking into account such things as
>SOAP, user-defined scripts, etc.

The key question is should the MailetEngine be run with the sames privileges
as "James"?

4) In what ways can/should james be hardened to increase security,
reliability and scalability?
- A more restricitve java.lang.SecurityManager could be used restricting
access to declared resources such as specific ports, files, directories,
- With multiple VMs on multiple machines clustering could be used to support
load-balancing, redundancy, maybe even automatic fallover. Support for these
behaviours is probably in the domain of Avalon/Phoenix rather than James
- To what extent should James be concerned with controlling the security of
OS executables (native code) launched from within James, and how can such
control be exerted in an OS independant manner?

5) Anything I've missed.

-- Steve

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message