Re: [exim] Exim vs. Qmail on Security

Nigel Metheringham schrieb:
> Marc Perkel wrote:
>> I suppose from the perspective of this conversation is that Exim as far as I can tell doesn't have a history of being reported as having security flaws. Secure means that a Qmail user who is thinking about moving to Exim can be told that Exim is as secure as Qmail is.
>>
> Its not.
Easy answer. Too easy. Never trust an easy answer.

> The big problem exim has is that it will fail badly - if something goes
> wrong you give away root. Qmail uses privilege separation techniques
> that mean it is very unlikely to give away root on failure.
You don't have to run an MTA with root-privileges. Not even setuid-root.
No matter which one.

You could run exim as the user "exim", have it listen to port 2525. Use
local iptables or something like that to redirect traffic to port 25 to
port 2525.
Something like "/sbin/iptables -t nat -I PREROUTING -p tcp --dport 25 -j
REDIRECT --to-port 2525" (untested).
That way exim binds to an unpriviliged port, no root-privileges required
at any time. Don't allow local user-accounts, so you don't have to
deliver to user-owned directories. If you care about security, you
wouldn't allow user-logins anyway, would you? You could use cyrus, so
you only have to make sure that exim has appropriate permissions to
connect to the lmtp-unix-socket (or choose lmtp over tcp). Run some
AV-software (e.g. kaspersky) which can run as a dedicated user without
root-permissions, as long as you give that user read-access to your
mail-spool. Run SpamAssassin with a spamassassin-user, you just have to
secure a unix-socket which exim uses to send data to spamassassin. Just
like the cyrus-issue.

Long storry cut short: you can do lots of advanced mail-processing
without any root-privileges at all.

Quite some trouble, but the worst thing an attacker could do is perform
some mail-operations, i.e. sending spam, avoid virus-scanning, etc. or
using local exploits for privilege-escalation. That is bad enough, of
course.


> In practice both packages will have security implicating bugs, but the
> qmail ones are far less likely to lose the complete game - although
> qmail is good at DOS conditions (causing them, that is).
Define "security" please.
If the only thing you care about is "security == no one gains
root-access", than a "normal exim-setup" compared to a "unpatched qmail"
probably is less secure.

If "security == no one tampers with e-mails" then the discussion starts
to get difficult.... privileged-separation would probably not help much,
perhaps not help at all, possibly causing additional attack-vectors,
thus qmail might even, under special conditions, be less secure.

If "security == no malware passes my system", then exim can easily use
exiscan to access av-software, qmail starts to get problems and needs
some kind of "extension", e.g. patches

Did I mention that running mail-setups like I'm used to would require
quite some qmail-patches? What about security when I run qmail with four
patches that have never been tested together before?

If we start to discuss reliability (which some might consider to be part
of security), the world is different again. qmail chooses one mx and
sticks to it after temporary failures, even if dozens of working mxes
are available... exim is quite uncontrolled regarding the number of
exim-processes. You can't establish a limit like "100 incoming
processes" or something like that, and indirect controls (max-load,
etc.) are just, well, indirect.....


>
> It depends what your priorities are. If you need absolute guarantees of
> absolute security then don't run an MTA (or an OS).
That would be so easy, I'd consider that to be cheating. ;-)

PS:
and yesterday I decided not to take the bait....


--
CU,
Patrick.