Flexible and Fine-grained Mandatory Access Control on Android for Diverse Security and Privacy Policies Sven Bugiel, Saarland University; Stephan Heuser, Fraunhofer SIT; Ahmad-Reza Sadeghi, Technische Universität Darmstadt and Center for Advanced Security Research Darmstadt This paper is included in the Proceedings of the 22nd USENIX Security Symposium. August 14–16, 2013 • Washington, D.C., USA ISBN 978-1-931971-03-4 Open access to the Proceedings of the 22nd USENIX Security Symposium is sponsored by USENIX Flexible and Fine-Grained Mandatory Access Control on Android for Diverse Security and Privacy Policies Sven Bugiel Stephan Heuser [email protected]∗ [email protected] Saarland University, Germany Fraunhofer SIT, Germany Ahmad-Reza Sadeghi [email protected] Technische Universität Darmstadt / CASED, Germany Abstract Android’s vulnerabilities. Android has been shown to be vulnerable to a number of different In this paper we tackle the challenge of providing attacks such as malicious apps and libraries that mis- a generic security architecture for the Android OS use their privileges [57, 40, 25] or even utilize root- that can serve as a flexible and effective ecosystem exploits [55, 40] to extract security and privacy sen- to instantiate different security solutions. In con- sitive information; taking advantage of unprotected trast to prior work our security architecture, termed interfaces [14, 12, 53, 32] and files [49]; confused FlaskDroid, provides mandatory access control si- deputy attacks [16]; and collusion attacks [46, 34]. multaneously on both Android’s middleware and kernel layers. The alignment of policy enforcement Solutions. On the other hand, Android’s open- on these two layers is non-trivial due to their com- source nature has made it very appealing to academic pletely different semantics. We present an efficient and industrial security research. Various extensions policy language (inspired by SELinux) tailored to to Android’s access control framework have been the specifics of Android’s middleware semantics. We proposed to address particular problem sets such as show the flexibility of our architecture by policy- protection of the users’ privacy [19, 28, 15, 52, 7, 30]; driven instantiations of selected security models such application centric security such as Saint enabling as the existing work Saint as well as a new privacy- developers to protect their application interfaces [39]; protecting, user-defined and fine-grained per-app ac- establishing isolated domains (usage of the phone cess control model. Other possible instantiations in private and corporate context) [9]; mitigation of include phone booth mode, or dual persona phone. Fi- collusion attacks [8], and extending Android’s Linux nally we evaluate our implementation on SE Android kernel with Mandatory Access Control [48]. 4.0.4 illustrating its efficiency and effectiveness. Observations. Analyzing the large body of litera- 1 Introduction ture on Android security and privacy one can make the following observations: First, almost all proposals Mobile devices such as smartphones and tablets have for security extensions to Android constitute manda- become very convenient companions in our daily lives tory access control (MAC) mechanisms that are tai- and, not surprisingly, also appealing to be used for lored to the specific semantics of the addressed prob- working purposes. On the down side, the increased lem, for instance, establishing a fine-grained access complexity of these devices as well as the increasing control to user’s private data or protecting the plat- amount of sensitive information (private or corporate) form integrity. Moreover, these solutions fall short stored and processed on them, from user’s location with regards to an important aspect, namely, that data to credentials for online banking and enterprise protection mechanisms operate only at a specific VPN, raise many security and privacy concerns. To- system abstraction layer, i.e., either at the middle- day the most popular and widespread smartphone ware (and/or application) layer, or at the kernel-layer. operating system is Google’s Android [4]. Thus, they omit the peculiarity of the Android OS design that each of its two software layers (middle- Author was affiliated with Technische Universität Darm- ware and kernel) is important within its respective stadt/CASED∗ at the time this work was conducted. semantics for the desired overall security and privacy. USENIX Association 22nd USENIX Security Symposium 131 Only few solutions consider both layers [8, 9], but problems of the stock Android permission framework they support only a very static policy and lack the and of related solutions which target either the mid- required flexibility to instantiate different security dleware or the kernel layer. We base our implemen- and privacy models. tation on SE Android [48], which has already been The second observation concerns the distinguishing partially merged into the official Android source-code characteristic of application development for mobile by Google1. platforms such as Android: The underlying oper- ating systems provide app developers with clearly 2. Security policy and type enforcement at mid- defined programming interfaces (APIs) to system dleware layer. We extended Android’s middleware resources and functionality – from network access layer with type enforcement and present our policy over personal data like SMS/contacts to the onboard language, which is specifically designed for the rich sensors. This clear API-oriented system design and semantics at this layer. The alignment of middleware convergence of functionality into designated service and kernel layer policies in a system-wide security providers [54, 36] is well-suited for realizing a security framework is non-trivial, particularly due to the dif- architecture that enables fine-grained access control ferent semantics of both layers. to the resources exposed by the API. As such, mobile 3. Use-cases. We show how our security framework systems in general and Android in particular provide can instantiate selected use-cases. The first one is an better opportunities to more efficiently establish a attack-specific related work, the well-known applica- higher security standard than possible on current tion centric security solution Saint [39]. The second commodity PC platforms [31]. one is a privacy protecting solution that uses fine- grained and user-defined access control to personal Challenges and Our Goal. Based on the obser- data. We also mention other useful security models vations mentioned above, we aim to address the fol- that can be instantiated with FlaskDroid. lowing challenges in this paper: 1) Can we design a generic and practical mandatory access control ar- 4. Efficiency and effectiveness. We successfully eval- chitecture for Android-based mobile devices, that uate the efficiency and effectiveness of our solution operates on both kernel and middleware layer, and by testing it against a testbed of known attacks and is flexible enough to instantiate various security and by deriving a basic system policy which allows for privacy protecting models just by configuring security the instantiation of further use-cases. policies? More concretely, we want to create a generic security architecture which supports the instantia- 2 Background tion of already existing proposals such as Saint [39] or privacy-enhanced system components [58], or even In this section, we first present a short overview of new use-cases such as a phone booth mode. 2) To the standard Android software stack, focusing on the what extent would the API-oriented design of An- relevant security and access control mechanisms in droid allow us to minimize the complexity of the place. Afterwards, we elaborate on the SE Android desired policy? Note that policy complexity is an Mandatory Access Control (MAC) implementation. often criticized drawback of generic MAC solutions like SELinux [33] on desktop systems [54]. 2.1 Android Software Stack Android is an open-source software stack tailored to Our Contribution. In this paper, we present the mobile devices, such as smartphones and tablets. It is design and implementation of a security architec- based on a modified Linux kernel responsible for basic ture for the Android OS that addresses the above operating system services (e.g. memory management, mentioned challenges. Our design is inspired by the file system support and network access). concepts of the Flask architecture [50]: a modular Furthermore, Android consists of an application design that decouples policy enforcement from the framework implementing (most of) the Android API. security policy itself, and thus provides a generic System Services and libraries, such as the radio inter- architecture where multiple and dynamic security face layer, are implemented in C/C++. Higher-level policies can be supported by the system. In particu- services, such as System settings, the Location- and lar, our contributions are: Audiomanager, are implemented in Java. Together, 1. System-wide security framework. We present an these components comprise the middleware layer. Android security framework that operates on both 1http://www.osnews.com/story/26477/Android_4_2_ the middleware and kernel layer. It addresses many alpha_contains_SELinux 132 22nd USENIX Security Symposium USENIX Association Android applications (apps) are implemented in during installation and checked by reference monitors Java and may contain native code. They are posi- in the Linux kernel at runtime.