Information Flow Control for Standard OS Abstractions Maxwell Krohn Alexander Yip Micah Brodsky Natan Cliffer Robert Morris M Frans Kaashoek Eddie Kohler UCLA MIT CSAIL http flume csail mit edu A BSTRACT such as fine grained control of information flow and high performance but require a shift in how applications are developed Flume instead provides process level DIFC as a minimal extension to the communication primitives in existing operating systems making DIFC work with the languages tools and operating system abstractions already familiar to programmers The Flume system provides DIFC at the granularity of processes and integrates DIFC controls with standard communication abstractions such as pipes sockets and file descriptors via a user level reference monitor Its interface helps programmers secure existing applications and write new ones with existing tools and libraries Flume enforces the DIFC policy as the application runs A typical Flume application consists of processes of two types Untrusted processes do most of the computation They are constrained by but possibly unaware of DIFC controls Trusted processes in contrast are aware of DIFC and set up the privacy and integrity controls that constrain untrusted processes Trusted processes also have the privilege to selectively violate classical information flow control for instance by declassifying private data perhaps to export it from the system or by endorsing data as highintegrity This privilege is distributed among the trusted processes according to application policy making it decentralized the D in DIFC Though bugs in the trusted code can lead to compromise bugs elsewhere in the application cannot and trusted code can stay relatively isolated and concise even as the application expands A central challenge for Flume is to accommodate processes that use existing communication interfaces such as sockets and pipes but also need to specify how and when they use their privileges It would be awkward to for example modify each call to read or write to take arguments indicating whether privilege should be applied Worse the conventional process interface is rife with channels that leak information like network sockets A system could simply mark these channels off limits restricting the process interface to those system calls with obvious and controllable information flow but this approach would make many libraries unusable Flume instead seeks to restrict access to these uncontrolled channels only when necessary Our solution is an endpoint abstraction Flume represents each resource a process uses to communicate as an endpoint including pipes sockets files and network connections A process can specify what subset of its privileges should be exercised when communicating through each endpoint Uncontrolled channels are modeled as endpoints that exit the DIFC system Flume ensures that no process can have both an uncontrolled channel and access to private data it cannot declassify We built Flume in user space with a few small kernel patches for implementation convenience and portability the implementation runs on Linux and OpenBSD Unlike prior systems that provide DIFC as part of a new kernel design e g Asbestos 8 and HiStar 38 Flume takes advantage of large existing efforts to maintain and improve the kernel support for hardware NFS RAID SMP etc The disadvantage is that Flume s trusted computing base is many times larger than those of dedicated DIFC kernels leaving Decentralized Information Flow Control DIFC 24 is an approach to security that allows application writers to control how data flows between the pieces of an application and the outside world As applied to privacy DIFC allows untrusted software to compute with private data while trusted security code controls the release of that data As applied to integrity DIFC allows trusted code to protect untrusted software from unexpected malicious inputs In either case only bugs in the trusted code which tends to be small and isolated can lead to security violations We present Flume a new DIFC model and system that applies at the granularity of operating system processes and standard OS abstractions e g pipes and file descriptors Flume eases DIFC s use in existing applications and allows safe interaction between conventional and DIFC aware processes Flume runs as a user level reference monitor on Linux A process confined by Flume cannot perform most system calls directly instead an interposition layer replaces system calls with IPC to the reference monitor which enforces data flow policies and performs safe operations on the process s behalf We ported a complex Web application MoinMoin wiki to Flume changing only 2 of the original code The Flume version is roughly 30 40 slower due to overheads in our current implementation but supports additional security policies impossible without DIFC Categories and Subject Descriptors D 4 6 Operating Systems Security and Protection Information flow controls Access controls D 4 7 Operating Systems Organization and Design C 5 5 Computer System Implementation Servers General Terms Security Design Performance Keywords distributed information flow control DIFC endpoints reference monitor system call interposition Web services 1 I NTRODUCTION As modern applications grow in size complexity and dependence on third party software they become more susceptible to security flaws Decentralized information flow control DIFC 24 a variant of classic information flow control 1 2 6 can improve the security of complex applications even in the presence of potential exploits Existing DIFC systems operate as programming language abstractions 24 or are integrated into communication primitives in new operating systems 8 38 These approaches have advantages Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page To copy otherwise to republish to post on servers or to redistribute to lists requires prior specific permission and or a fee SOSP 07 October 14 17 2007 Stevenson Washington USA Copyright 2007 ACM 978 1 59593 591 5 07 0010 5 00 321 311 it vulnerable to security flaws in the underlying operating system Also Flume s user space implementation incurs some performance penalties and may expose covert channels that deeper kernel integration would close