A Portable User-Level Approach for System-Wide Integrity Protection†
Total Page：16
File Type：pdf, Size：1020Kb
A Portable User-Level Approach for System-wide Integrity Protectiony Wai-Kit Sze and R. Sekar Stony Brook University Stony Brook, NY, USA ABSTRACT • Difficulty of secure policy enforcement. Non-bypassable poli- In this paper, we develop an approach for protecting system in- cies usually have to be enforced in the OS kernel. They are usu- tegrity from untrusted code that may harbor sophisticated malware. ally much harder to develop than user-level defenses. Moreover, We develop a novel dual-sandboxing architecture to confine not kernel-based solutions cannot be easily ported across different only untrusted, but also benign processes. Our sandboxes place OSes, or even different versions of the same OS. only a few restrictions, thereby permitting most applications to An alternative to sandboxing is isolated execution of untrusted code. function normally. Our implementation is performed entirely at One-way isolation [15, 23] permits untrusted software to read any- the user-level, requiring no changes to the kernel. This enabled us thing, but its outputs are held in isolation. Two-way isolation limits to port the system easily from Linux to BSD. Our experimental re- both reads and writes, holding the inputs as well as outputs of un- sults show that our approach preserves the usability of applications, trusted applications in an isolated environment. The app model on while offering strong protection and good performance. Moreover, Android, Apple iOS, and Windows 8 sandbox are generally based policy development is almost entirely automated, sparing users and on this two-way isolation model. administrators this cumbersome and difficult task. Isolation approaches provide stronger protection from malware since they block all interactions between untrusted and benign soft- 1. Introduction ware, thereby preventing subversion attacks. They also provide The state-of-practice in malware defense relies on reactive mea- much better usability because they permit sufficient access for most sures, such as virus scanning and software patches. While this prac- applications to work. However, they too have several significant tice may have been adequate in the past, it cannot cope with today’s drawbacks, especially in the desktop environment: sophisticated malware that employ complex evasion and subversion • Fragmentation of user data. Unlike sandboxing, which contin- techniques to overcome deployed defenses. It is thus important to ues to support the model of a single namespace for all user data, develop principled defenses that provide reliable protection regard- isolation causes a fragmentation: user data is partitioned into less of malware sophistication. two or more containers, each representing a disjoint namespace. A natural (and perhaps the best studied) proactive defense is to • Inability to compose applications. The hallmark of today’s desk- sandbox potentially malicious code. This approach can be applied top OSes is the ability to compose applications together. UNIX to software from untrusted sources [11], which may be malicious pipelines represented one of the early examples of application to begin with; or to software from trusted sources [16, 6, 20] that is composition. Other common forms of composition can happen benign to start with, but turns malicious due to an exploit. However, through files or scripts, e.g., printing a spread sheet into a PDF there are several challenges with sandboxing untrusted code: file and then emailing this PDF file. Unfortunately, strict isola- • Difficulty of policy development. Experience with SELinux [16] tion prevents one application from interacting with any data (or and other projects [3, 22] show that policy development requires code) of other applications, thus precluding composition. a great deal of expertise and effort. Moreover, policies that • No protection when isolation is breached. Strict isolation may provide even modest protection from untrusted code can break be breached either due to a policy relaxation, or through manual many legitimate applications. copying of files across isolation contexts. Any malware present • Subversion attacks on benign software. Even highly restrictive in such files can subsequently damage the system. policies can be inadequate, as malware can co-opt benign appli- In contrast, our approach combines the strengths of sandboxing cations to carry out prohibited operations: Malware may trick a and isolation of untrusted code, while avoiding most of their weak- user to run a benign application in insecure ways or exploit vul- nesses. Like sandboxing, all user data is held within one name nerabilities in benign applications to perform arbitrary actions. space, thereby providing a unified view. Like isolation, our ap- Permission to make digital or hard copies of all or part of this work for per- proach preserves the usability of applications, and does not require sonal or classroom use is granted without fee provided that copies are not significant policy development effort. At the same time, it avoids made or distributed for profit or commercial advantage and that copies bear the weakness of isolation-based approaches, allowing most typi- this notice and the full citation on the first page. Copyrights for components cal interactions between applications, while ensuring that system of this work owned by others than the author(s) must be honored. Abstract- security isn’t compromised by these interactions. An open-source ing with credit is permitted. To copy otherwise, or republish, to post on implementation of our system is available [26]. servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. ACSAC ’13, December 09 - 13 2013, New Orleans, LA, USA yThis work was supported in part by grants from NSF (CNS- Copyright held by the owner/author(s). Publication rights licensed to ACM. 0831298) and AFOSR (FA9550-09-1-0539). ACM 978-1-4503-2015-3/13/12 ...$15.00. Term Explanation 1.1.1 Secure enforcement and tracking without OS changes malicious intentionally violate policy, evade enforcement Our approach encodes integrity labels into file ownership and untrusted possibly malicious permission. In particular, untrusted files are those that are owned benign program non-malicious but may contain vulnerabilities by a set of newly created untrusted userids, or are writable by these benign process process whose code and inputs are benign, hence non-malicious users. Untrusted processes are all run with an untrusted userid. This encoding enables us to leverage existing OS mechanisms for Figure 1: Key terminology tracking and propagating integrity labels. In particular, note that files as well as child processes inherit their ownership from that 1.1 Approach Overview and Salient Features of the process that created them. As a result, any file or process Sophisticated malware can evade defenses using multi-step at- created by an untrusted process will have the label of untrusted. tacks, with each step performing a seemingly innocuous action. Benign processes and files are characterized by their ownership For instance, malware may simply deposit a shortcut on the desk- by a userid other than an untrusted userid. In addition, benign files top with a name of a commonly used application instead of writing will have write permissions that make them unwritable by untrusted files in system directories directly. It can wait until the user double- userids. As a result, files created by benign processes will have clicks on this shortcut and do its work. Alternatively, malware may benign labels, once again ensuring correct propagation of labels. deposit files that contain exploits for popular applications, with the In addition to tracking integrity labels, our userid-based encod- actual damage inflicted when a curious user opens them. The first ing also provides the foundation for sound policy enforcement with- example involves a benign process executing code derived from a out OS kernel changes. Specifically, existing OS mechanisms can malicious source, while the second example involves a vulnerable correctly enforce policies on untrusted processes: by virtue of our benign application being compromised by malicious data. integrity label encoding, benign files have permission settings that To thwart all malware attacks regardless of the number of steps make them unwritable by untrusted userids. Although we need to involved, we use integrity labels to systematically track the influ- develop additional enforcement mechanisms for benign processes, ence of untrusted sources on all files. Files coming from the OS e.g., to prevent them from reading untrusted files, this is a con- vendor (and any other source that is trusted to be non-malicious) siderably simpler task than policy enforcement on untrusted code. are given the label benign (Figure 1), while the remaining files are In particular, challenges in secure policy enforcement arise mainly given the label untrusted. Note that benign programs may con- due to evasion attacks. Since benign processes cannot be malicious, tain exploitable vulnerabilities, but only untrusted programs can be they won’t attempt evasion. Indeed, a simple yet secure implemen- malicious, i.e., may intentionally violate policy and/or attempt to tation can be developed within the address space of a benign pro- evade enforcement. Exploitation of vulnerabilities can cause be- cess, e.g., by replacing libc, which makes all system calls on behalf nign programs to turn malicious. However, an exploit represents of a process, with a version