Application-Defined Decentralized Access Control Yuanzhong Xu and Alan M. Dunn, The University of Texas at Austin; Owen S. Hofmann, Google, Inc.; Michael Z. Lee, Syed Akbar Mehdi, and Emmett Witchel, The University of Texas at Austin https://www.usenix.org/conference/atc14/technical-sessions/presentation/xu This paper is included in the Proceedings of USENIX ATC ’14: 2014 USENIX Annual Technical Conference. June 19–20, 2014 • Philadelphia, PA 978-1-931971-10-2 Open access to the Proceedings of USENIX ATC ’14: 2014 USENIX Annual Technical Conference is sponsored by USENIX. Application-Defined Decentralized Access Control Yuanzhong Xu Alan M. Dunn Owen S. Hofmann ∗ Michael Z. Lee Syed Akbar Mehdi Emmett Witchel The University of Texas at Austin Google, Inc.∗ Abstract Decentralized privilege. In Linux and Windows, users and groups are principals, and can be assigned privileges. DCAC is a practical OS-level access control system that A user might consider creating another user (a “sub- supports application-defined principals. It allows normal principal”) and assigning it a subset of her privileges. users to perform administrative operations within their This allows an application to run as the sub-principal, privilege, enabling isolation and privilege separation for and thus with restricted privileges compared to the case applications. It does not require centralized policy spec- where the user directly runs the application. However, on ification or management, giving applications freedom to Linux and Windows, administrative functions on users manage their principals while the policies are still en- and groups require root privilege. As a result, current OS- forced by the OS. DCAC uses hierarchically-named at- level access control does not allow many applications to tributes as a generic framework for user-defined policies run with least privilege. such as groups defined by normal users. For both local DCAC decentralizes administrator privilege: a nor- and networked file systems, its execution time overhead mal user can perform administrative operations within is between 0%–9% on file system microbenchmarks, and her privilege, like creating principals with subsets of her under 1% on applications. privilege. Privilege separation makes complex applica- This paper shows the design and implementation of tions more difficult to exploit. But current systems re- DCAC, as well as several real-world use cases, includ- quire administrative involvement to install and deploy ing sandboxing applications, enforcing server applica- privilege-separated software. tions’ security policies, supporting NFS, and authenticat- For example, the suEXEC feature of Apache HTTP ing user-defined sub-principals in SSH, all with minimal Server allows it to run CGI and SSI programs under UIDs code changes. different from the UID of the calling web server, by using 1. Introduction setuid binaries. However, creating UIDs for CGI/SSI programs and setting up the setuid binaries requires Continued high-profile computer security failures and administrator privilege. Not only can use of administra- data breaches demonstrate that computer security for ap- tive privilege require human involvement, it also adds op- plications is abysmal. While there is extensive research portunities for configuration mistakes that can actually into novel security and access control models little of harm security. The suEXEC documentation1 warns the this work has an impact on practice. Instead of appli- user, “if suEXEC is improperly configured, it can cause cations consistently reimplementing security vulnerabili- any number of problems and possibly create new holes ties, they need a practical and expressive way to use thor- in your computer’s security. If you aren’t familiar with oughly debugged system-level primitives to achieve best managing setuid root programs and the security issues security practices. they present, we highly recommend that you not con- DCAC (DeCentralized Access Control) is our attempt sider using suEXEC.” By contrast, DCAC allows forms to make modern security mechanisms practical for ac- of privilege separation, like delegating user privileges to cess control. It has three distinguishing characteristics: it sub-principals, that even in the case of a configuration is decentralized in privilege, decentralized in policy spec- mistake, limit the effect of a compromise to the privi- ification, and allows application-defined principals and leges of the original user. synchronization requirements. Although DCAC greatly OS-level access increases the flexibility of access control, it retains a Decentralized policy specification. control typically defines its principals and policies in a familiar model of operation, with per-process metadata centralized, secure location, such as the /etc/group checked against per-object ACLs to determine the al- file, the policy.conf file in SELinux, or a central pol- lowed access. It relies on the standard OS infrastructure icy server (e.g., a Lightweight Directory Access Protocol of a hierarchical file namespace, extended file attributes, (LDAP) server). DCAC decentralizes policy specifica- and file descriptors. It is practical for distributed envi- tion: policies are stored in files and file metadata at arbi- ronments because it avoids requiring centralized storage, trary locations. DCAC generalizes the setuid mecha- consistency, or management. nism of Unix, allowing processes to use the file system 1 ∗ Work completed while at the University of Texas at Austin. http://httpd.apache.org/docs/2.4/suexec.html USENIX Association 2014 USENIX Annual Technical Conference 395 to gain fine-grained, user-defined privileges (i.e., not just 2. Modern access control idioms root). With DCAC, applications control their privileges with a mechanism implemented and enforced by the op- We discuss three access control idioms common in to- erating system, but without central coordination. day’s web-connected applications that are difficult to DCAC is particularly practical for distributed environ- achieve in modern systems: sandboxing, ad hoc shar- ments, e.g., where machines share a file system via NFS. ing, and managing users. Because these idioms are not In such an environment, applications simply use the file well served by current system security abstractions, ap- system to express access control policy, and any host that plications constantly reimplement these idioms, and im- mounts the file system will enforce identical access con- plement them poorly. Section 3.2 shows how DCAC sup- trol rules. DCAC does not add its own synchronization ports them more naturally than current systems. requirements, such as entries in a central database. Ap- Privilege separation/Sandboxing. Suppose Alice wish- plications make all access control decisions with access es to run a photo management program. By default, her only to their own files. In contrast, a centralized policy program will run with the same privileges as her user server might become a bottleneck when policy queries account. However, routines for interpreting file formats and updates are frequent, as in many server applications. are often subject to exploitable bugs (such as in the zlib library used to decompress .png files [1]). If Alice re- Application-defined principals: attributes. Attributes ceives photos from untrusted sources, or even if Alice make applications simpler and more secure by allowing makes a mistake, all of her potentially sensitive files are them to use access control implemented by the operating endangered, rather than just those that should be man- system rather than reimplementing their own. Traditional aged by her photo management application. Running OS principals, such as users, are heavy-weight abstrac- untrusted or partially-trusted applications has become tions that cannot be directly used by applications e.g., a commonplace, as users frequently download applications web application that manages its own users. from less than trusted sources, or run applications that are DCAC attributes are hierarchically named strings. often exploitable, such as pdf viewers. Strings are separated into components by the “.” char- In order to separate her application into a separate acter. The string .u.alice can represent the user Alice, privilege domain, Alice must contact an administrator to but applications are free to define their own encodings create a new user (e.g. alice-photos), potentially create a and even their own principals. For example, the string new group containing both her and alice-photos so that .p.387.1357771171 might be a principal referring to a she may easily share files, and install support for running process with identifier 387 started about 1.4 billion sec- her desired application as the new user, such as via a onds after January 1, 1970; .app.browser.password setuid binary. While it is possible to enforce privilege might be a component of a browser that is responsible restriction without superuser support, solutions that do so for storing and retrieving the user’s passwords. A pro- require complex application-level support (such as in the cess may carry multiple attributes simultaneously. Chromium web browser [6]) that are easy to get wrong, with disastrous results (e.g., the frequent exploits enabled by bugs in the Java VM’s sandboxing mechanism [2, 3]). Practicality. DCAC combines ideas from mandatory This scenario is an example of privilege separation, access control (MAC) systems [7, 16], sandboxing [6], a well-known technique for building secure applica- and decentralized information flow control