[Mailman-Users] chroot jails (Was: First-time poster...)

[John Dennis]

On Tue, 2005-06-07 at 02:42 -0700, Bill Landry wrote:

> Doh, ended up being a chroot issue in master.cf.  Thanks John, Mark, and Dan 
> for the responses, and my apologies to the list for the noise...

Glad you got it fixed.

I'd like to take this opportunity to make a few comments about chroot
jails, this is not directed at you or your choice to use them but rather
as a general comment of interest to the wider community.

For what its worth I see this as a prime example of why I no longer
recommend people run postfix (and other services) in a chroot jail. We
stopped shipping postfix chrooted several years ago after observing the
inordinate amount of problems it created for a marginal security win.
Postfix is now often configured to interact with a host of other
software components (SASL, TLS, SQL databases, LDAP directories, mailing
list managers, spam filters, challenage/response authentcation methods,
etc.) and as such its tenticles reach deep and wide. Trying to keep all
these diverese elements in sync in a jail is a headache and a source of
numerous problems often ascribed as bugs but which aren't. Even Wietse
Venema the author of postfix no longer recommends the use of chroot
jails although this was a design center of the original postfix security
model. Chroot jails can be broken out of. Even without chroot jails
postfix maintains a fairly robust security profile because of its
design.

Finally, with the advent of SELinux (yes, postfix, mailman, and apache
are under the control of SELinux on Red Hat systems) the value of a jail
is greatly diminished in favor of the vastly more robust security model
inherent in SELinux. In fact it might be a reasonable statement that
SELinux is itself a system wide jail enforced at the kernel level for
every process and every object (e.g. files, sockets, devices, etc.). It
is a Mandatory Access Control (MAC) sytem which means it cannot be
defeated and offers great granularity (and unforuntely its own set of
new headaces as the wrinkles in the security policy are ironed out ;-)

-- 
John Dennis <jdennis at redhat.com>