1Background: Every few months CERT announces Yet Another Security Hole In 2Sendmail---something that lets local or even remote users take complete 3control of the machine. I'm sure there are many more holes waiting to be 4discovered; sendmail's design means that any minor bug in 46000 lines of 5code is a major security risk. Other popular mailers, such as Smail, and 6even mailing-list managers, such as Majordomo, seem nearly as bad. 7 8Note added in 1998: I wrote the above paragraph in December 1995, when 9the latest version of sendmail was 8.6.12 (with 41000 lines of code). 10Fourteen security holes were discovered from sendmail 8.6.12 through 118.8.5. See http://pobox.com/~djb/docs/maildisasters/sendmail.html. 12 13I started working on qmail because I was sick of this cycle of doom. 14Here are some of the things I did to make sure that qmail will never let 15an intruder into your machine. 16 17 181. Programs and files are not addresses. Don't treat them as addresses. 19 20sendmail treats programs and files as addresses. Obviously random people 21can't be allowed to execute arbitrary programs or write to arbitrary 22files, so sendmail goes through horrendous contortions trying to keep 23track of whether a local user was ``responsible'' for an address. This 24has proven to be an unmitigated disaster. 25 26In qmail, programs and files are not addresses. The local delivery 27agent, qmail-local, can run programs or write to files as directed by 28~user/.qmail, but it's always running as that user. (The notion of 29``user'' is configurable, but root is never a user. To prevent silly 30mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is 31group-writable or world-writable.) 32 33Security impact: .qmail, like .cshrc and .exrc and various other files, 34means that anyone who can write arbitrary files as a user can execute 35arbitrary programs as that user. That's it. 36 37 382. Do as little as possible in setuid programs. 39 40A setuid program must operate in a very dangerous environment: a user is 41under complete control of its fds, args, environ, cwd, tty, rlimits, 42timers, signals, and more. Even worse, the list of controlled items 43varies from one vendor's UNIX to the next, so it is very difficult to 44write portable code that cleans up everything. 45 46Of the twenty most recent sendmail security holes, eleven worked only 47because the entire sendmail system is setuid. 48 49Only one qmail program is setuid: qmail-queue. Its only purpose is to 50add a new mail message to the outgoing queue. 51 52 533. Do as little as possible as root. 54 55The entire sendmail system runs as root, so there's no way that its 56mistakes can be caught by the operating system's built-in protections. 57In contrast, only two qmail programs, qmail-start and qmail-lspawn, 58run as root. 59 60 614. Move separate functions into mutually untrusting programs. 62 63Five of the qmail programs---qmail-smtpd, qmail-send, qmail-rspawn, 64qmail-remote, and tcp-env---are not security-critical. Even if all of 65these programs are completely compromised, so that an intruder has 66control over the qmaild, qmails, and qmailr accounts and the mail queue, 67he still can't take over your system. None of the other programs trust 68the results from these five. 69 70In fact, these programs don't even trust each other. They are in three 71groups: tcp-env and qmail-smtpd, which run as qmaild; qmail-rspawn and 72qmail-remote, which run as qmailr; and qmail-send, the queue manager, 73which runs as qmails. Each group is immune from attacks by the others. 74 75(From root's point of view, as long as root doesn't send any mail, only 76qmail-start and qmail-lspawn are security-critical. They don't write any 77files or start any other programs as root.) 78 79 805. Don't parse. 81 82I have discovered that there are two types of command interfaces in the 83world of computing: good interfaces and user interfaces. 84 85The essence of user interfaces is _parsing_---converting an unstructured 86sequence of commands, in a format usually determined more by psychology 87than by solid engineering, into structured data. 88 89When another programmer wants to talk to a user interface, he has to 90_quote_: convert his structured data into an unstructured sequence of 91commands that the parser will, he hopes, convert back into the original 92structured data. 93 94This situation is a recipe for disaster. The parser often has bugs: it 95fails to handle some inputs according to the documented interface. The 96quoter often has bugs: it produces outputs that do not have the right 97meaning. Only on rare joyous occasions does it happen that the parser 98and the quoter both misinterpret the interface in the same way. 99 100When the original data is controlled by a malicious user, many of these 101bugs translate into security holes. Some examples: the Linux login 102-froot security hole; the classic find | xargs rm security hole; the 103Majordomo injection security hole. Even a simple parser like getopt is 104complicated enough for people to screw up the quoting. 105 106In qmail, all the internal file structures are incredibly simple: text0 107lines beginning with single-character commands. (text0 format means that 108lines are separated by a 0 byte instead of line feed.) The program-level 109interfaces don't take options. 110 111All the complexity of parsing RFC 822 address lists and rewriting 112headers is in the qmail-inject program, which runs without privileges 113and is essentially part of the UA. 114 115 1166. Keep it simple, stupid. 117 118See BLURB for some of the reasons that qmail is so much smaller than 119sendmail. There's nothing inherently complicated about writing a mailer. 120(Except RFC 822 support; but that's only in qmail-inject.) Security 121holes can't show up in features that don't exist. 122 123 1247. Write bug-free code. 125 126I've mostly given up on the standard C library. Many of its facilities, 127particularly stdio, seem designed to encourage bugs. A big chunk of 128qmail is stolen from a basic C library that I've been developing for 129several years for a variety of applications. The stralloc concept and 130getln() make it very easy to avoid buffer overruns, memory leaks, and 131artificial line length limits. 132