[1007] in linux-security and linux-alert archive
Re: [linux-security] sendmail security
daemon@ATHENA.MIT.EDU (Ian Jackson)
Wed Aug 14 01:53:23 1996
Date: Tue, 13 Aug 96 14:06 BST
From: Ian Jackson <ian@chiark.chu.cam.ac.uk>
To: Nathan Ramella <floyd@ecst.csuchico.edu>
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199608081858.LAA15240@corpse.ecst.csuchico.edu>
(Apologies to everyone for prolonging this, but I'm loathe to allow
this kind of FUD-spreading to go unchallenged.)
[Mod: Let's try and call it a wrap on this subject; it's starting to
approach the warfare stage, and thus is probably best handled via
private e-mail messages. Thanks! --Jeff.]
Nathan Ramella writes ("Re: [linux-security] sendmail security"):
...
> Might I just comment, I'm sure smail has just as many holes as
> sendmail, if not more.. The reason it's supposedly "secure" is
> because smail is a little more low profile than sendmail.
Ah, I see: sod the brilliant sword of truth and go for the chainsaw of
blatant assertion. Have you actually read any of Smail's source code,
or even its documentation ? We should be careful of people saying `X
is not secure' with no evidence, just as we should be careful of
people saying `Y is secure'.
There are good reasons, besides the very low number of known security
exposures in Smail compared to very high number in sendmail, to think
that Smail is much more secure than sendmail.
The configuration scheme and overall design is much simpler, and
security has obviously been considered at the outset of the design
(though it hasn't been given top priority).
In particular, Smail's approach to running programs as a result of
incoming messages is much more careful than sendmail's (and much more
easily configured and controlled), and even tends to err excessively
on the side of caution sometimes.
Having read parts of the source code I can say that what I have seen
is of a generally high quality, and I would be surprised if it had
more than one or two buffer overrun bugs (I would hesitate to say that
it has none, but none have been identified so far).
Furthermore, Smail is being used a lot more lately. This increase in
use is in part due to Smail's simplicity and - paradoxically - its
lack of flexibility. The fact that Smail can't do header rewriting
and many of the other grungy hacks that sendmail is capable of means
that it's harder to configure it to make grungy messes by mistake :-).
This makes Smail unsuitable for situations where you need these
features, but this is less necessary nowadays unless you're running a
mail hub which has to talk to broken LAN mail systems.
...
> If smail ever got "really popular", it would probably suffer the
> same growing pains that sendmail has gone through, and will continue
> to go through.
>
> (And a side note, anyone who thinks they're 'more secure' because
> of smail is relying on security through obscurity, and is only
> kidding themselves.)
Your assertions are without foundation.
> If you _really_ want security, try running sendmail through inetd,
> uid(nobody), gid(mail), and hack in some pgp encryption to the
> mail spool. Just running smail won't do it, or even more to the point
> NOT running sendmail definitly won't do it.
Not running sendmail _will_ _definitely_ protect you against the
security exposures that it has had that allow remote users to gain a
shell on your system. Running sendmail without root privilege will
help, of course, but it is a fact of life that attacking a Unix system
from the inside is very much easier than from the outside.
Running an important daemon as `nobody' is a bad idea, of course.
Create a special account (or use an existing system account like
`mail').
Ian.
