################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally published in the Proceedings of the Fourth USENIX UNIX Security Symposium Santa Clara, California, October 4-6 1993. For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: http://www.usenix.org Sendmail without the Superuser Mark E. Carson Secure Workstations Department IBM Federal Sector Company, 182/3F42 Gaithersburg, MD 20879 carson@vnet.ibm.com Abstract As an exercise in the application of the concept of least privilege, we have modified the pieces of an ordinary UNIX* mail system, sendmail in particular, to require little or no privilege in their operation. No mail code runs with root or system IDs. In fact, the simplest configuration (local-only mail, with or without mandatory access controls) can run with no privilege or special access rights whatsoever, while even the most complex (multilevel network mail) can be done with minimal privilege requirements. While such modifications cannot guarantee the absence of security holes in mail, they should greatly limit their possible scope. ----------------------------- *UNIX is a trademark of UNIX Systems Laboratory, Inc. AIX is a trademark of IBM. XENIX is a trademark of Microsoft. Introduction One of the more interesting principles for the design of secure software is the idea of least privilege: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job."[1] This is not so much a security feature in the sense of access control or labeling as it is an admission of limitation -- that despite our best efforts it is likely that at least some privileged software we write will have flaws, so that in order to minimize the potential effects of these flaws, we should minimize the privilege our software requires to run. One of the more notorious examples of the need for this is provided by the UNIX mail system, sendmail in particular. In addition to the well-known debug-mode hole exploited by the Internet worm, a variety of other flaws have been found in various mail implementations over the years.[2] Considering the size and complexity of the mail-related code, this is hardly surprising. As an experiment with least privilege, we have analyzed the privilege requirements of mail and created a mail system which provides full functionality, yet requires little or no privilege for most of its operation. This paper describes this analysis and design. Least privilege In the system under consideration (an experimental variant of AIX 3.2), in common with several other modern versions of UNIX, there are several avenues to "least privilege": 1. Least access rights. Where programs run with additional access rights (i.e. setuid or setgid to some administrative or "system" ID), these rights should be as limited as possible. 2. Least kernel privileges. "Kernel privileges" are extraordinary rights for normally-restricted system calls (tested for by suser() in traditional UNIX), such as described in [3] for Secure XENIX (now Trusted XENIX). The set granted to a program should be as small as possible. 3. Least use of privileges. Even where additional access rights or kernel privileges are needed, they are generally required for only small portions of a program. Hence where sensible, these added privileges may be "lapsed" (temporarily) or "dropped" (permanently) when not needed. 4. Least amount of code with privilege. In some cases, it may be helpful to divide a privileged program in two -- a (hopefully small) privileged part, and a (hopefully larger) nonprivileged part. This can avoid possible problems with privileged code in a large program accidentally (through bugs or in response to signals) branching to other code which was not intended to be executed with privileges still in effect. 5. Controlled environment for privileged code. Many security problems have arisen because privileged code has been called (maliciously) in a fashion or environment it was not properly designed to handle. If the environment for running privileged code can be closely controlled (for example, it cannot be called directly by ordinary users, or is not privileged when so called), the chance for such problems is reduced. We note below how we make use of all of these approaches in our mail architecture. First we will describe the normal mail architecture and analyze its use of privilege. Normal mail architecture The "normal" mail architecture described here is that of AIX 3.2; however, it is quite typical of most UNIX systems today. The mail system consists of three parts: a front end mail viewer/creator (in this instance mail(x), mh), the middle man (sendmail or rmail), and the backend local mail delivery agent (bellmail). Only the first of these is directly called by the typical user, but of course, on a UNIX system, any of these (even sendmail, or for that matter telnet to the SMTP port) can also be used directly by those hardy souls who think ed is an editor with too many frills. The front end tools allow viewing and saving incoming mail and composing outgoing messages. Incoming mail is read from the file /var/spool/mail/. Sendmail is invoked to handle any outgoing messages. The front ends are relatively complex programs and have not (in AIX) been privileged (setuid or setgid) in the past, so it is clearly out of the question to make them so now. Sendmail fills several different roles. It is invoked directly as a delivery intermediary by the front end mailers. It runs as a daemon process to accept incoming SMTP mail and to retry queued mail which could not be sent earlier. And it can be invoked administratively to "compile" updated configuration files. Typically, sendmail runs setuid/setgid root/system, needing privilege for a variety of reasons. Rmail is an intermediary for UUCP mail; it basically sits between UUCP and sendmail, and has no special privilege requirements. The normal backend delivery agent is simply the old Bell Labs mailer, which wrote directly to mailboxes. Bellmail normally runs setuid root in order to write to everyone's mailbox. The backend for "program" mailing (such as when vacation is used) is typically the Bourne shell sh, running with the recipient's ID, hopefully unprivileged. There are a few other pieces in the mail system. Comsat is part of an old mail notification scheme. When delivering mail, bellmail sends a datagram to the biff udp port. If so configured, inetd will have bound that port, and will start up comsat on receiving a datagram. It in turn reads /etc/utmp to see who's logged on, and the datagram to see who the mail is to. If the recipient is logged on and has the `x' bit set on the login tty (usually by a separate program, biff), comsat opens the recipient's mailbox and copies a few lines of the new mail to the recipient's terminal. Since this scheme can be used indirectly to write arbitrary data to another user's tty, it represents something of a security hole if enabled. As most users use notification tools like xbiff nowadays, little effort need be expended trying to preserve this design. New mail discretionary access architecture Discretionary access handling follows the model first used for Secure XENIX mail.[4] The mail middlemen and backends are made setgid mail, rather than setuid root. The various mail configuration files, directories and mailboxes are then set up to be writeable by group mail. This allows the whole mail system to work without any exemption from discretionary access control. Mail administration (e.g. compiling alias files) requires only membership in group mail, rather than root ID. Only mail-related files are (installed) in this group, so granting mail administration rights does not grant any other extraordinary rights. There are two visible effects of this access architecture. First of all, users who set up forwarding of their mail must ensure their .forward file (or their mailbox for those using the old bellmail scheme) be readable as well by group mail. Secondly, when mailing to a user for the first time, bellmail must have the privilege to give away newly created mailboxes. (This is a privileged operation in BSD-like systems, to prevent evasion of disk quotas.) This can be accomplished either by having initial mail sent by a privileged user (as is typically done for test purposes on account creation), or by granting bellmail this (limited) privilege. [In the environment with mandatory access controls described below, where users may have multiple mailboxes, the latter may be the only practical course.] New mail mandatory access architecture This mail system was designed to run as well in an environment with mandatory access controls, of the sort described in the TCSEC.[5] Again, mail mandatory access handling expands on the Secure XENIX model. The spool directory (/var/spool/mail) is changed into a multilevel directory. This "transparently redirects" mail activity at any level into the "hidden" subdirectory appropriate for that level. Effectively, users have separate mailboxes for every security level. The same approach is taken for the local storage areas for the different mailers. For mh, only the main mh directory ($HOME/Mail) need be marked multilevel. This is done as a separate administrative action, requiring no change to the mh commands. For mail(x) , since the default mailbox ($HOME/mbox) and dead letter ($HOME/dead.letter) files are directly in the home directory, we must modify the code to allow for an intermediate (multilevel) directory, making the files $HOME/mbox/mbox and $HOME/dead.letter/dead.letter. For local mail under normal circumstances, mail is delivered immediately: mail(x) or mh calls sendmail, which in turn calls the local mailer (bel lmail). Hence the entire string will run naturally at the same mandatory access level, achieving the desired affect. Mail sent over a single-level network connection (UUCP or SMTP/TCP/IP) will have the obvious limitation that it can be sent only if the sender is at the level of the network connection. Mail sent over multilevel networks will automatically be sent at the appropriate level. Incoming network mail on a single-level network is handled correctly automatically by a daemon-mode sendmail running at the network's level. In the case of a multilevel network, which at least in our case has only a single TCP port name space, privilege is required to accept connections at any mandatory access level. Since such a privilege could easily be exploited to bypass the mandatory access policy, special care is required in its use. For our project, we used the "privilege lapse/drop" <|,"4">approach: the privilege required to accept connections at arbitrary levels is "lapsed" ( made non-effective) in the sendmail daemon except around the actual accept() call. Sendmail then determines the level of the new connection, and creates a child process at that level. This child then (permanently) drops all mandatory access-related privileges before handling the message. Hence we can at least say the process actually handling the SMTP traffic is unprivileged, which should effectively preclude any exploitation of this privilege by external attacks. Especially over the network, mail sending may be subject to delays. In this case, sendmail puts the message in a queue directory (/var/spool/mqueue), for later delivery by the daemon-mode invocation of sendmail, which is normally configured to examine the queue directory every 30 minutes. We have made the queue directory multilevel as well. In the absence of privilege, daemon mode sendmail (typically invoked with the flags -b d -q30m) can only handle the queue subdirectory at its level. To avoid any privilege use, additional invocations of sendmail can be made at other levels with only the -q30m flag to provide queue processing services at those levels. Obviously, this multiple-queue-daemon method is somewhat awkward if a large number of levels are in use. Since multiple queues will essentially only occur with a multilevel network, the privileged daemon-mode invocation needed in this case does have sufficient privilege to examine all queues at all levels; it then invokes (unprivileged) children to retry queued mail at the level it was queued. An alternative architecture for both of these cases, which we are looking to implement in a future version, is to use the privilege/non-privilege divide approach. A separate, inetd-like program would listen for and accept new connections, then invoke a (non-privileged) sendmail at the appropriate level to handle the SMTP traffic. Periodically as well it would check for queued mail, and invoke a queue-handling (non-privileged) sendmail at the appropriate level as needed. This approach has the advantage of removing all mandatory access exemptions from sendmail code. It also has a good security structure in the sense that the privileged code invokes the non-privileged code rather than the other way around; this can help ensure privileged code will only execute in a defined, controlled environment. New mail privilege architecture Our basic approach to minimizing privilege granted to sendmail is the controlled environment one; in our system, the sendmail executable itself is not marked with privilege; any privileges an invocation of sendmail has must be inherited from its caller. Hence normal direct user invocations of sendmail are unprivileged. Sendmail only has privilege when invoked in daemon mode, where it inherits privilege (in AIX) from the "super daemon" srcmstr. Srcmstr actually passes all privileges to the programs it invokes; to avoid having sendmail invoked with unneeded or undesired privileges (and to handle certain technical problems with the system), we follow the privilege division approach, where srcmstr actually invokes a small program sendshell, which drops all but a defined set of privileges before calling the real sendmail program. The discussion above covered mail's privilege requirements from the standpoint of access control. There are a few other privilege requirements as well. To bind to the "privileged" SMTP TCP port, the daemon-mode invocation of sendmail requires a privilege; this can be dropped immediately after the port is bound, so should be reasonably harmless. Again, the alternative architecture described above, where a "sendmail inetd" handles the port binding and connection acceptance, would entirely obviate the need for this privilege in sendmail. More seriously, to perform "program mailing" (for example, when a user has set up the vacation program to answer incoming mail), sendmail must have privilege so that it can run the recipient's program with the recipient's ID. Unfortunately, program mailing has been the target of attacks in the past (this was the area of the debug hole exploited by the Internet worm); while the current code seems quite reasonable, we cannot expect to provide complete assurance for it. On a multilevel system with users having different clearances, there is the additional difficulty that a user could, by setting up program mailing for his/her account, indirectly get processes to run under his/her own ID at levels above his/her clearance. This is presumably not too serious a difficulty, since such processes could not directly communicate higher-level information to the user (barring other security holes in the system, of course), but this may be a sensitive subject to some. For these reasons, we basically throw up our hands and say program mailing is enabled only by administrator discretion. An administrator may allow it simply by providing sendmail with the needed privilege in general, or by running sendmail queue daemons with this privilege (which will provide delayed program mailing services.) If enabled, sendmail is at least careful not to pass any privileges on to the program mailer. We have added auditing capabilities to sendmail to record any "unusual" activity (in particular, program mailing, mailing directly to a pathname, and any administrative activity). Again, an administrator may easily configure sendmail auditing, by deciding whether or not to give sendmail audit privileges. Comsat Since comsat is basically an obsolete approach in the X world, all we have done with it is to make sure it drops all privileges on invocation. This means it can only find out about mail arrivals at its level, can only read mail sent to publicly readable mailboxes, and can only send notification to users logged in to that level with writeable ttys. With such a setup, comsat at least is not introducing any additional security holes, though of course anyone who goes through the effort of enabling comsat notification of mail has rendered his tty vulnerable to write "bombs." Future work For a future extension of this work, we are using this system as the transmission means for more sophisticated mailers, in particular a "true" multilevel mailer which handles individual multilevel messages -- messages where individual parts may have varying security characteristics. Here the multilevel mailer determines the least upper bound of these characteristics and uses it as the "envelope" label for invoking the appropriate level mailer. Conclusions The changes described here should greatly limit the damage possible through attacks on mail. Even with the additional functionality required for mandatory access, the changes to mail are relatively small -- some 500 out of 26,000+ lines in sendmail, and 200 out of 16,000+ in other code. References [1] J.H. Saltzer, M. Schroeder. "The Protection and Control of Information Sharing in Computer Systems," Proc. of IEEE, Vol. 63, No. 9, September 1975. [2] See e.g. CERT Advisories CA-90:01, CA-90:08, CA-91:01a, CA-91:13, CA-91:14. [3] M.S. Hecht, M.E. Carson, C.S. Chandersekaran, R.S. Chapman, L.J. Dotterer, V.D. Gligor, W.D. Jiang, A. Johri, G.L. Luckenbaugh, N. Vasudevan. "UNIX without the Superuser," Summer 1987 USENIX Technical Conference Proceedings, Phoenix, Arizona. [4] M.E. Carson, W.D. Jiang, J.G. Liang, D.H. Yakov. "Toward a Multilevel Document System," Proceedings of the AIAA/ASIS/IEEE 3rd Aerospace Computer Security Conference, Orlando, Florida, 1987. [5] Department of Defense Computer Security Center, Trust ed Computer System Evaluation Criteria, DoD 5200.28-STD, December 1985. Availability An earlier version of this code is included in the AIX-based Compartmented Mode Workstation (CMW).