Date: Mon, 18 Nov 1996 13:17:21 +1030 (CST) From: newton@communica.com.au (Mark Newton) To: batie@agora.rdrop.com (Alan Batie) Cc: imp@village.org, adam@homeport.org, pgiffuni@fps.biblos.unal.edu.co, freebsd-security@freebsd.org Subject: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2). Message-ID: <9611180247.AA15359@communica.com.au> In-Reply-To: <m0vPIKD-0008rpC@agora.rdrop.com> from "Alan Batie" at Nov 17, 96 05:16:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Batie wrote:
> > Sendmail is well understood and well maintained with a very long track
> > record. Other mailers, no matter how much better, don't match this
> > track record.
>
> Yup, sendmail has a long track record of the "security hole of the month";
> I've yet to see one for smail. I would like to switch to sendmail, as I
> hear it deals with mail queues a lot better these days, and smail
> development seems to have gone into a black hole, but until sendmail can
> make it a whole month or two without a CERT advisory on it...
Of course, one of the main reasons why sendmail is so "dangerous" is that
despite fifteen years of it-hurts-when-I-do-this style experience, we *still*
run it as root! Why do we do this? Why does nobody understand that a UNIX
process can't just gratuitously gain privileges unless some other privileged
program gives them away? Given sendmail's history, why do so many people
still trust it with root privileges when it doesn't actually need them?!
sendmail really only needs root so that it can bind to the "privileged"
port 25 when it's running in daemon mode. If you frob filesystem permissions
sufficiently you can get away without providing sendmail with root
privileges by running it with a non-root uid out of inetd (which is,
indeed, precisely what I have done with it here at Communica, where
sendmail runs as the unprivileged "smtp" user).
Tradeoff: High-volume sites will not like the fact that it doesn't run
as a daemon, because it has extra overhead associated with fork()/exec()
from inetd.
On the other hand, the fact that it a) isn't running as a daemon here; and
b) wouldn't have any scary privileges if it did has given me a warm fuzzy
glow in the context of the latest bug.
- mark
---
Mark Newton Email: newton@communica.com.au
Systems Engineer Phone: +61-8-8373-2523
Communica Systems WWW: http://www.communica.com.au
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9611180247.AA15359>