A Comparison of Unix Sandboxing Techniques

SEE TEXT ONLY A Comparison of Unix Sandboxing Techniques Why sandboxing is different from historic approaches to Unix oday's users need more protection than tradi- T tional Unix systems have been able to deliver. security, how we got The authors of operating systems have tradi- tionally had a great deal of interest in systemic notions where we are, and how of privilege (e.g., the authority to inject code into the kernel via modules), but the users of computing sys- Capsicum compares with tems often require finer-grained models of access con- Linux’s seccomp(2) and trol (e.g., the ability to share a single contact or delegate management of a single calendar). Rather than OpenBSD’s pledge(2). protecting multiple users from each other, the operating systems of today's end-user devices must protect single users from their applications and those applications from each other. Historic Unix-derived systems have not made this task easy; in some cases, the protection users need has not even been possible. Protection was a first-class objective of early, gener- BY JONATHAN ANDERSON al-purpose operating systems and the hardware on which they ran [Lamp69, And72, SS72]. This early focus led naturally to the exploration and design of rigorous, general-purpose protection primitives such as capabilities [DV66] and virtual memory [BCD69, Lamp69]. In the transition from Multics to Unix domi- nance, this focus was lost. The result was a highly portable operating system that would go on to domi- nate contemporary thinking about operating systems, but with security features primarily organized around one threat model: users attacking other users (including accidental damage done by buggy software under development). This security model—Discretionary This work has been sponsored by the Research and Development Corporation of Newfound- land and Labrador (contract 5404.1822.101) and the NSERC Discovery program (RGPIN-2015- 06048), the Defense Advanced Research Projects Agency (DARPA), and the Air Force Research Laboratory (AFRL) (contract FA8650-15-C-7558). 16 FreeBSD Journal Access Control (DAC)—can be implemented with of sandboxing required relatively small code Unix owner/group/other permissions or with changes to meet their security objectives, which Access Control Lists (ACLs), but it does not pro- tended to fit the coarse-grained security model vide adequate support for application sandbox- of DAC or the system-security perspective of ing. FreeBSD, Linux, and MacOS eventually MAC. Less successful forays into sandboxing acquired frameworks for enforcing systemic secu- required thousands of lines of code, sometimes rity policies such as multi-level security and with large amounts of hand-crafted assembly, a integrity enforcement [WFMV03, WCM+02, requirement for system (superuser) privilege • Wat13], collectively known as Mandatory Access and—often—a failure to truly enforce the desired Control (MAC). Such policies represent the inter- security policy. ests of system owners and administrators and An early—and relatively successful—imple- provide an additional dimension along which mentation of sandboxing was Provos et al’s privi- enforcement can be specified, but they are bet- lege separation of the OpenSSH server [PFH03]. ter-suited to tasks such as protecting high- This work used discretionary access control fea- integrity files from low-integrity data than to sup- tures to prevent a compromised SSH server porting sandboxing in unprivileged applications. process from exercising the privileges of the The goal of sandboxing is to protect users superuser. The SSH server requires superuser priv- from their own applications when those applica- ilege in order to bind to TCP port 22, but it is tions are exposed to untrusted content. Complex desirable that a compromised SSH process not be applications are regularly exposed to content able to access system resources such as the from malicious sources, often embedded within filesystem before a user has authenticated (i.e., difficult-to-parse protocols and file formats. This the server should be put into a pre-auth sand- is especially true on the Internet, where even the box); it is also desirable that the server post- most basic use cases involve ASN.1 parsing (for authentication only be able to exercise the TLS) as well as parsing documents, Web pages, authority granted to the authenticated user (from images, and videos as well as interpreting scripts within a post-auth sandbox). Provos et al split the or encoding/decoding cookies. Even the humble SSH server process into a trusted monitor process file(1) command was patched in 2014 for vul- that retained superuser privilege and untrusted nerabilities in its parsing code [SA14:16]. Once a child processes that would use the superuser process is compromised by malicious content, the privilege to drop privilege, changing their user goal of a sandboxing policy is to limit the poten- and group IDs to those of unprivileged users. In tial for damage to a small set of known outputs. the pre-auth sandbox, an SSH server process For example, a compromised word processor may could run as the nobody user and have its root be able to corrupt its output files, but it should directory changed to an empty directory using not be able to search through a user's home the chroot(2) system call. In the post-auth directory for private keys or credit card details. sandbox, a process would have its UID/GID Sandboxing-specific features (or, as they are changed to those of the authenticated user. This sometimes referred to, attack-surface–reduction approach to sandboxing was successful for two features) such as FreeBSD's Capsicum, reasons: OpenBSD's pledge(2), and Linux's seccomp(2) 1. User-oriented policy: The goal of SSH have appeared comparatively recently; we com- privilege separation is to keep compromised pare their effectiveness below. processes from exercising the authority of the superuser. This policy goal aligns well with Sandboxing with DAC/MAC the Unix DAC model: it can be expressed Prior to the introduction of sandboxing features entirely in terms of UIDs, GIDs, and filesystem in commodity operating systems, valiant efforts directories with Unix permissions. The policy were made to confine or sandbox applications does not protect a user from misbehavior with the tools that were available. These efforts post-authentication: it protects the system met with varying degrees of success, depending and other users. on how well the designed security policy fit onto 2. Extant privilege: Operations such as a discretionary or mandatory access control (DAC changing a process's UID or root directory or MAC) model. The most successful applications require superuser privilege, which the SSH Sept/Oct 2017 17 server undergoing privilege separation already access, but unlike OpenSSH, the superuser privi- possessed. The sshd process was already a lege required to use chroot(2) is not naturally security-critical piece of software run as root: found in Web browsers (or office suites, music privilege separation was a monotonic decrease players, other desktop applications, etc.). Thus, in in authority. This is not the case for the more order to avail of the DAC-based protection that general case of sandboxing, however: it is did exist, portions of the application had to be undesirable to require unprivileged software to shipped with the setuid bit set on a root- run as root in order to drop privilege. owned binary!1 At the other end of the spectrum, we have pre- Mandatory Access Control (MAC) is also a poor viously compared several DAC- and MAC-based fit for application sandboxing. It requires a dual approaches to sandboxing renderer processes in coding of policy: once in the code that describes the Chromium web browser [WALK10]. In that what the application does and once in a separate work, we found that DAC and MAC mechanisms policy that describes what the application is were a poor fit for the application compartmen- allowed to do. The SELinux policy from our origi- talization use case. DAC is designed to protect nal Capsicum comparison involved thousands of users from each other, but in the case of a Web lines of policy, but even modern AppArmor pro- browser—or any other sophisticated, multiprocess files encoded in a domain-specific language can user application—the security goal is to limit the require hundreds of lines of subtle and complex damage that can be done by a rogue process policy, not including policy elements included from after it is compromised by untrusted content. system policy libraries (e.g., #include DAC alone cannot control access to unlabeled <abstractions/ubuntu-browsers.d/ objects such as System V shared memory (in java>). It can be very difficult to write and main- Linux) or FAT filesystems (in Windows). As with tain complex MAC policies, with failures in func- OpenSSH, chroot(2) can be used to put a tionality (e.g., a lack of access to @{PROC}/[0- process into an environment of limited filesystem 9]*/oom_score_adj) being more obvious to 1 Today's Chrome no longer uses the DAC-based sandbox on Linux, but the above comments about chroot(2) and privilege still apply to the new sandboxing model. ZFSBy Brooks experts Davis, Robert Norton, make Jonathan their Woodruff &servers Robert N. M. Watson Now you can too. Get a copy of..... Choose ebook, print, or combo. You’ll learn to: • Use boot environment, make the riskiest sysadmin tasks boring. • Delegate filesystem privileges to users. • Containerize ZFS datasets with jails. • Quickly and efficiently replicate data between machines. • Split layers off of mirrors. • Optimize ZFS block storage. • Handle large storage arrays. • Select caching strategies to improve performance. • Manage next-generation storage hardware. • Identify and remove bottlenecks. • Build screaming fast database storage. • Dive deep into pools, metaslabs, and more! Link to: WHETHER YOU MANAGE A SINGLE SMALL SERVER OR INTERNATIONAL DATACENTERS, SIMPLIFY YOUR STORAGE WITH FREEBSD MASTERY: ADVANCED ZFS.

Load more