Make Least Privilege a Right (Not a Privilege) Maxwell Krohn∗, Petros Efstathopoulosy, Cliff Frey∗, Frans Kaashoek∗, Eddie Kohlery, David Mazieres` z, Robert Morris∗, Michelle Osbornez, Steve VanDeBogarty and David Ziegler∗ ∗MIT yUCLA zNYU [email protected] ABSTRACT ized mandatory access control [17]. The end result is a Though system security would benefit if programmers new operating system called Asbestos. routinely followed the principle of least privilege [24], 2 LESSONS FROM CURRENT SYSTEMS the interfaces exposed by operating systems often stand in the way. We investigate why modern OSes thwart se- Administrators and programmers can achieve POLP by cure programming practices and propose solutions. pushing the features in modern Unix-like operating sys- tems, but only partially, and with important practical 1 INTRODUCTION drawbacks. Though many software developers simultaneously revere 2.1 chrooting or jailing Greedy Applications and ignore the principles of their craft, they reserve spe- cial sanctimony for the principle of least privilege, or Because Unix grants privilege with coarse granularity, POLP [24]. All programmers agree in theory: an applica- many Unix applications acquire more privileges than tion should have the minimal privilege needed to perform they require. These “greedy applications” can be tamed its task. At the very least, five POLP requirements must with the chroot or jail system calls. Both calls con- be followed: (1) split applications into smaller protec- fine applications to jails, areas of the file system that tion domains, or “compartments”; (2) assign exactly the administrators can configure to exclude setuid executa- right privileges to each compartment; (3) engineer com- bles and sensitive files. FreeBSD’s jail goes further, munication channels between the compartments; (4) en- restricting a process’s use of the network and interpro- sure that, save for intended communication, the compart- cess communication (IPC). System administrators with ments remain isolated from one another; and (5) make it enough patience and expertise can chroot or jail easy for anyone to audit the intended separation. standard servers such as Apache [1], BIND [3] and send- Unfortunately, modern operating systems make these mail [26], though the process resembles stuffing an ele- requirements onerous, dangerous, or impossible to ap- phant into a taxicab. ply. In our experience (detailed in Section 2.2), build- Even when possible, the chroot/jail approach ing least-privileged software is cumbersome and labor- faces more fundamental drawbacks: intensive: following POLP feels more like an abuse of the Jails are heavyweight. The jailed file system must operating system’s interface than a judicious use of its contain copies of system-wide configuration files (such features. Most programmers spare themselves these dif- as resolv.conf), shared libraries, the run-time linker, ficulties by reverting to monolithic, over-privileged ap- helper executable files, and so on. Maintaining collec- plication designs. Such neglect exposes machines to at- tions of duplicated files is an administrative difficulty, tacks both old and new, from remote attacks on privi- especially on systems with many jailed applications. leged servers to “install attacks” (exploiting users’ will- Jails are coarse-grained. Running a process in a ingness to run high-privilege installers to infect machines jail is similar to running it on its own virtual machine. with malware). We cannot write bug-free applications or Two jailed applications can share files only if one’s prevent honest users from occasionally executing mali- namespace is a superset of the other, or if inefficient cious code. Instead, our best hope is to contain the dam- workarounds are used, such as NFS-mounting a local file age of evil code by resurrecting POLP. system. In this paper, we examine some ways that current Jails require privilege. Unprivileged users may not OSes discourage development of least-privilege appli- call chroot or jail.1 Jails are therefore ill-suited for cations (Section 2), then propose OS design ideas that containing the many untrusted applications that should might encourage it instead. A first approximation of a not have privileges, such as executable email attachments POLP-friendly system is one based on capabilities, dis- or browser plugins. cussed in Section 3. Though capabilities have historically Finally, chroot or jail’s ex post facto imposition flummoxed application designers, we present a more fa- of security is no substitute for POLP-based design. For miliar interface, based on the Unix file system. In Sec- example, a typical dynamic content Web server (such as tion 4, we discuss shortcomings in this proposed design: Apache with PHP [18]) runs many logically unrelated system weaknesses might still allow vulnerabilities to scripts within the same address space. A vulnerability in spread, and process-sized compartments are too coarse- any one script exposes all other scripts to attack, regard- grained. We then propose a solution based on decentral- less of whether the server is jailed. 2. Obtain unused UID and GID ranges on the system. 3. Assign the ith worker its own UID ui and GID gi. 4. Allocate a writable coredump directory for each UID. 5. Change the ith worker’s executable to have owner root, group gi, and access mode 0410. 6. Call chroot. 7. For each worker process i: kill all processes running as user ui or group ID gi; fork; change user ID to ui and group ID to gi; chdir into the dedicated dump directory; and call exec on the correct executable. The chown call in Step 5, the chroot call in Step 6, and the setuid call in Step 7 all require privileged sys- tem access, so the launcher must run as root. Unix offers no guarantees of an atomic UID reservation (as required Figure 1: Block diagram of the OKWS system. Standard processes are in Step 2) or race-free file system permission manipula- shaded, while site-specific services and databases are shown in white. tions (as required throughout). Even ignoring these po- The privileged launcher process launches the demux, publisher, log- tential security problems, this design requires involved ger and the site-specific services. The databases shown might either be IPC to coordinate worker and helper processes. running locally, or on different machines. Other systems use similar techniques to solve related 2.2 Ad-Hoc Privilege Separation problems. Examples include remote execution utilities such as OpenSSH [23] and REX [10], and mail transfer True privilege separation is possible on Unix through agents such as qmail [2] and postfix [21]. Considering a collection of ad-hoc techniques. For instance, our these applications and others, a trend emerges: in each POLP-based OK Web Server (OKWS) [12] uses a pool instance, the intricate mechanics of privilege separation of worker processes to sequester each logical function are invented anew. To audit the exact security procedures of the site (e.g. /show-inbox, /change-pw, and of these applications, one must comb tens of thousands /search) into its own address space. The demux, a of lines of code, each time learning a new system. Even small, unprivileged process, accepts incoming HTTP re- automated tools that separate privileged operations [5] quests, analyzes their first lines, and forwards them to the require root access. appropriate workers using file descriptor passing. Work- ers then respond to clients directly. A privileged launcher 2.3 A User-Level POLP Library? process starts this process suite, ensuring that processes At first glance, a user-level POLP library might seem are jailed into empty subtrees of the file system, and able to abstract the security-related specifics of appli- that they do not have the privileges to interact with one cations like OKWS, qmail, and so on. One such ex- another. Finally, since workers’ chroot environments ample of this approach is found in the Polaris system prohibit them from accessing the root file system di- for Windows XP [30], which applies POLP to virus- rectly, they write HTTP log entries and read static HTML prone client applications like Web browsers and spread- content via small, unprivileged helper processes: the log- sheets2 via chroot-like compartments. Such solutions ger and the publisher, respectively. Figure 1 shows a have three drawbacks. First, they require privileged ac- block diagram of a simple OKWS configuration. cess to the system. Second, libraries must work around The goal of this design is to separate application logic the lack of good OS support for sharing across com- into disjoint compartments, so that any local vulnerabil- partments: since jailed processes work with copies of ity (especially in site-specific worker processes) cannot files, synchronization schemes are required to reconcile spread. In particular, workers cannot send each other sig- copies after changes. (For example, Polaris email plug- nals or trace each other’s system calls, they cannot ac- ins run in a jail with a copy of the attachment; a persistent cess each other’s databases, they cannot alter any exe- “synchronizer” process updates the original if the plug-in cutable or library, and they cannot access each other’s changes the copy.) Finally, we suspect that POLP tech- coredumps. Unfortunately, achieving these natural re- niques used in more complicated servers such as OKWS quirements complicates OKWS. Its launcher must: do not generalize well. As evidence, both OKWS and REX, an ssh-like login facility, use the same libraries (the 1. Establish a chroot environment, with the correct SFS toolkit [16]) but share little security-related code. file system permissions, that contains the appro- This comes as no surprise since the two have different se- priate shared libraries, configuration files, run-time curity aims: OKWS hides most of the file system, while linker, and worker executables. REX exposes it to authorized users; OKWS must support millions of possible users, while REX serves only those such as “current working directory” and “file system with login access to a given machine; application design- root”.