> -----Original Message----- > From: dalek [mailto:wvdat_private] > Sent: Thursday, February 28, 2002 9:09 AM > To: secprogat_private > Subject: designing a secure mail server? > > 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. Sendmail supports TLS between MTAs. I don't believe doing TLS to the local delivery agent (i.e. LMTP) would be hard to achieve. > Now please, I know all about qmail and I am using it at a site I admin, > I am not looking for suggestions on what to use, what I am looking for > are some links and papers that deal with things like safely binding to > a high port (25) and dropping privileges, Sendmail 8.12.x does that. It's no longer installed setuid by default. The daemon has to start as root because there's no other way to bind to port 25, but user instances and forked children all run as "smmsp" or whatever user is designated. The binary is installed setgid to "smmsp", which is the group of the queue directory to which clients can write. Users can't get root through the binary from the command line, at all, ever (unless you know a way to elevate privileges without setuid). > safe email address parsing so as to exclude characters which might be > used to redirect the mail or even launch programs on the machine running > the MTA, etc... This is a hard problem to solve, because arguably unsafe characters are perfectly valid according to the RFCs. However, plenty of work has been done to enforce such things, like "smrsh". Address parsing isn't the right approach, in my opinion. When you construct the argv of something the MTA wants to execute, as little as possible of the format of the command should be user-provided. The MTA should control the path of the binary being executed and all of the arguments passed to it. For example, one would never use a "%s" substitution based on user data when building an argument set. If for example I try to deliver to user "foo;/sbin/reboot" and the MTA is dumb enough to just run the command "mail.local -d %s" substituting the above string, and mail.local runs as root, you're sunk. This approach means you don't have to anticipate all the possibilities for all the combinations of characters you might get from an attacker. The operating system and the child process (which isn't running as root) validate the data for you. The child process is free to discover that its parameters are invalid and report such to the MTA, and no harm befalls the system. > Also, input and opinions about currently operating MTAs and their > strengths and weaknesses would be appreciated. The "SECURITY" file in the current Sendmail open source distribution talks about some of these issues. Others are just good common programming practise. I can't speak to the strengths and weaknesses of other MTAs without spouting what would really be raw opinion rather than fact. > Let me give you an idea on some of the thoughts that have been going > through my head regarding MTAs. > > 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. The design of Sendmail 9 is in progress. It's more in line with this requirement. > [...] > 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) I'm not sure how you can avoid this on UNIX if you're truly security conscious. Running things as users dedicated to the task (or at least some non-root unprivileged user like "nobody") is pretty much a necessity, unless you're willing to certify that your application is bullet-proof and take the heat when you discover that it isn't. > Please share your opinions about this idea before I head off on a > tangent and start a big project that might or might not be fundamentally > broken due to bad design. I think anyone who believes writing a secure MTA that handles all of the specs properly is underestimating what a daunting task that is. It would be much better to work on improving the security of current implementations. -- Ralph Logan CEO/Founder Camisade Application Security Innovations 832.496.8448
This archive was generated by hypermail 2b30 : Thu Feb 28 2002 - 14:01:25 PST