Re: designing a secure mail server?

From: Nicholas Brawn (ncb@pobox.com)
Date: 02/28/02


Date: Fri, 1 Mar 2002 09:52:45 +1100
To: "dalek" <wvd@type01.com>
From: Nicholas Brawn <ncb@pobox.com>


On Friday, March 1, 2002, at 02:08 AM, dalek wrote:

> I have been thinking long and hard about the design of a secure MTA,
> preferably one that does SMTP and local (to the spool) as well as
> remote (SMTP) delivery.
>

<snip>

> 1) I dont want to write a monolithic single binary server that forks off
> parts of itself at different privilege levels to do different tasks. I
> dont
> know
> if it is even possible to exploit, but having ALL the functions to ALL
> the
> different tasks of the MTA in the same address space as the instance
> that accepts user input makes me uneasy.

Good thinking on the monolithic binary idea. I believe that most
security conscious developers recognise that security is to be found in
lots of smaller, separate pieces of code/programs which by their nature
are more easy to audit than a big single program. This is the approach
that DJB has taken with his many programs.

>
> 2) I dont want to rewrite major, well known, used everywhere unix system
> components to run my mailserver, like DJB did with his inetd
> replacement.
>

You may find that rewriting some applications is better in the long run.
Especially if you plan on having reduced functionality (only the bare
features necessary for better security) as part of your MTA. Feature
creep in programs that have been around for a while may lend itself to
vulnerabilities. This probably won't be necessary unless the programs
that run your MTA require special privileges to do so - or if you go to
the effort to analyse just how they will interact with your MTA and
security implications of different operations.

> 3) I dont want to put the MTA binaries and configuration files in non
> traditionaly unix directories (once again like qmail), Configurations go
> in /etc and binaries go into either /usr/local, /usr or /bin depending
> on
> the distro / flavour of unix you prefer.
>

That's not really a problem. However you will need to provide some
migration script to ease installation and wrappers for programs that
expect the presence of sendmail (for example).

> 4) I dont want to modify the directory structure or other misc. bits of
> metadata like directory ownership and permissions of the traditional
> unix mail spools, eg: /var/spool/mqueue, /var/mail (on OpenBSD)
>

There have been lots of debates on how to handle mail spool permissions.
I seem to recall a big one on Bugtraq back when Wietse Venema was
initially proposing/designing Postfix. Hunt them down and check out what
they're discussing - I think it comes down to how much privileges you
give to programs that need to read from the mail spool vs. types of
attacks against the mail spool locally.

Cheers,
Nick

--
Real friends help you move bodies.



Relevant Pages

  • Re: [PATCH] Add compile domain
    ... Your MTA? ... For a robust installation of all of them you specify the name, ...
    (Linux-Kernel)
  • designing a secure mail server?
    ... I have been thinking long and hard about the design of a secure MTA, ... remote (SMTP) delivery. ... I dont want to write a monolithic single binary server that forks off ...
    (SecProg)
  • Designing a secure mail server
    ... > I have been thinking long and hard about the design of a secure MTA, ... The "SECURITY" file in the current Sendmail open source distribution talks ... The design of Sendmail 9 is in progress. ... I think anyone who believes writing a secure MTA that handles all of the ...
    (SecProg)
  • Re: Anti Virus for Linux?
    ... When was the last security ... And how so those malicious attachment concern a MTA at all? ... squid + squidguard or squid + dansguard make a nice http proxy ... mean with "malicious incoming web traffic"? ...
    (comp.os.linux.misc)
  • Re: which mta to choose
    ... > time like every other MTA like Postfix, qmail exim and so on. ... YOu seem to suggest that Sendmail had roughly the same amount of security ...
    (alt.os.linux)