sendmail security (compared to other MTAs)
blm...@myrealbox.com
been arguing in another venue about whether sendmail deserves
its apparent reputation as a security risk (I'm on the "I think
maybe it doesn't" side), and it would be nice to get some expert
opinions, hence this post ....
Certainly there were security problems with early versions of
the program, at least one of which had major consequences (the
(in)famous Morris worm), but as best I can tell, there aren't
a lot of problems being reported via CERN, and the ones that
are reported are being fixed. I notice that many Linux
distributions seem to be moving away from sendmail in favor
of other MTAs, but my guess is that this has as much to do
with ease/difficulty of configuration as with security.
Can anyone point me to authoritative sources of information?
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
David F. Skoll
> I don't mean to launch any kind of religious war here, but I've
> been arguing in another venue about whether sendmail deserves
> its apparent reputation as a security risk (I'm on the "I think
> maybe it doesn't" side), and it would be nice to get some expert
> opinions, hence this post ....
In my opinion, Sendmail's design is not as secure as Postfix's design;
a single large monolithic process is harder to secure than smaller,
mutually-distrustful separate processes.
However, Sendmail's implementation has certainly been cleaned up
over the last few years and its security has improved, especially with
the advent of 8.12 which no longer required a SUID-root binary.
> I notice that many Linux
> distributions seem to be moving away from sendmail in favor
> of other MTAs, but my guess is that this has as much to do
> with ease/difficulty of configuration as with security.
I agree. Sendmail is seen as a pain in the neck to configure, and
as "old-fashioned". I happen to like its flexibility.
> Can anyone point me to authoritative sources of information?
This is a rather old article, but good:
http://www.seifried.org/security/technical/20010924-postfix.html
A somewhat-biased pro-Postfix article:
http://archives.neohapsis.com/archives/postfix/2000-07/0119.html
I use Sendmail (because of Milter, primarily), but I'm always checking
out Postfix developments.
Regards,
Davd.
blm...@myrealbox.com
(I'm restoring the crosspost to comp.mail.sendmail, which I'm
only now noticing was removed, since I do rather want to hear
opinions from sendmail advocates. If you feel strongly about
not continuing the discussion there, say so and I'll honor the
Followup-To next time.)
In article <3a1cc$4a68f553$d1d97a75$30...@PRIMUS.CA>,
Thanks! both useful -- though for the latter one I found some
of the later posts in the thread more helpful.
Two points I had not thought about, but which do seem like valid
reasons to regard sendmail with at least a bit of suspicion:
(*) One huge program does seem more difficult to secure than several
small ones.
(*) If sendmail must run as root, while other MTAs can run as a
less-privileged user, yeah, the consequences of flaws in sendmail
would seem to be potentially worse.
> I use Sendmail (because of Milter, primarily), but I'm always checking
> out Postfix developments.
--
ska
> (*) One huge program does seem more difficult to secure than several
> small ones.
Although, many would agree to this idea, a debate ends in an endless
religious flame war. One has to design the communicaton between the
processes well now.
I'm not a supporter of this idea right away.
For instance, qmail uses several processes for different tasks, but
introduces backscatter, because it finds out too lately, whether or
not a recipient is valid. This habbit resulted in a lot of individual
patches http://spamlinks.net/prevent-secure-backscatter.htm#reject-qmail
> (*) If sendmail must run as root, while other MTAs can run as a
> less-privileged user, yeah, the consequences of flaws in sendmail
> would seem to be potentially worse.
sendmail does not require to run as root. It cannot do the built-in
delivery tasks, without being root (well, it can, but very limited),
but you can define your own MDA, which probably needs sertuid then
like with any other MTA.
And any MTA needs to be root at some point, in order to bind to port
25 and 587.
ska
Andrzej Adam Filip
> [...]
> And any MTA needs to be root at some point, in order to bind to port
> 25 and 587.
It is not true. It merely means that "simple minded"/"classic"
approaches do not deliver it.
Do not be afraid to be clever :-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
There's nothing worse for your business than extra Santa Clauses
smoking in the men's room.
-- W. Bossert
David F. Skoll
> blmblm @ myrealbox. com wrote:
>> (*) One huge program does seem more difficult to secure than several
>> small ones.
> Although, many would agree to this idea, a debate ends in an endless
> religious flame war. One has to design the communicaton between the
> processes well now. I'm not a supporter of this idea right away.
It does seem to be the wave of the future for MTAs, though. qmail (ugh)
and Postfix both use this design, as does MeTA1: http://www.meta1.org/
(MeTA1 is being written by Claus Aßmann, a well-known Sendmail hacker,
though development seems rather slow lately.)
AFAIK, Exim and Sendmail 8 are the only monolithic free MTAs left.
Regards,
David.
Andrzej Adam Filip
> ska <s...@mail.inf.fh-brs.de> wrote:
>
>> [...]
>> And any MTA needs to be root at some point, in order to bind to port
>> 25 and 587.
>
> It is not true. It merely means that "simple minded"/"classic"
> approaches do not deliver it.
>
> Do not be afraid to be clever :-)
To provide one sample solution:
Unixes support passing open file descriptors between unrelated processes.
It makes possible to use *simple* daemon running as root to provide MTA
running *always* as non root socket listening on "root reserved" port.
[ e.g. http://hans.liss.pp.se/node/711 ]
P.S.
Sendmail closes SMTP socket when system gets too high and reopens it
when system load gets lower.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Of course it's possible to love a human being if you don't know them too well.
-- Charles Bukowski
David F. Skoll
> To provide one sample solution:
> Unixes support passing open file descriptors between unrelated processes.
> It makes possible to use *simple* daemon running as root to provide MTA
> running *always* as non root socket listening on "root reserved" port.
> [ e.g. http://hans.liss.pp.se/node/711 ]
That (IMO) is more complicated that dropping privileges after you fork.
A simple accept loop in the main sendmail process is easier to audit
for security than an accept loop in a daemon that then goes through all
the hoops of passing the accepted file descriptor over a UNIX-domain socket
to Sendmail.
If you are really concerned, you use port-forwarding tricks. If you
are really, really, really concerned, you run Sendmail in a virtual
machine like KVM and have the whole KVM process run as an unprivileged
user.
I think that's all pointless; dropping privileges after fork is fine.
-- David.
Claus Aßmann
> To provide one sample solution:
> Unixes support passing open file descriptors between unrelated processes.
> It makes possible to use *simple* daemon running as root to provide MTA
> running *always* as non root socket listening on "root reserved" port.
You mean like mcp (based on inetd) and smtps in MeTA1?
For start_action = pass the option pass_fd_socket must be specified; in
this case MCP binds to the specified socket (listen_socket) and passes
it via the Unix domain socket (pass_fd_socket) to the started process.
Andrzej Adam Filip
1) I was thinking not only about getting open socket at startup.
e.g. sendmail-8 closes the socket in too high load situation and
reopens it when load gets lower
2) Have you considered creating (small) daemon providing such
functionality to *other* applications?
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
A man of genius makes no mistakes.
His errors are volitional and are the portals of discovery.
-- James Joyce, "Ulysses"
Claus Aßmann
> Claus Aßmann
> 1) I was thinking not only about getting open socket at startup.
> e.g. sendmail-8 closes the socket in too high load situation and
> reopens it when load gets lower
That shouldn't be too hard to add. However, I don't need it; I wrote a
program to inform my firewall to block connection from "offenders",
no need to shut down the server.
> 2) Have you considered creating (small) daemon providing such
> functionality to *other* applications?
mcp/inetd.c is open source, feel free to use it.