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.
This archive was generated by hypermail 2b30 : Thu Feb 28 2002 - 14:58:41 PST