SEApp: Bringing Mandatory Access Control to Android Apps Matthew Rossi Dario Facchinetti Università degli Studi di Bergamo Università degli Studi di Bergamo [email protected] [email protected] Enrico Bacis∗ Marco Rosa Stefano Paraboschi Università degli Studi di Bergamo SAP Security Research Università degli Studi di Bergamo [email protected] [email protected] [email protected] Abstract A peculiar threat that characterizes mobile operating sys- Mandatory Access Control (MAC) has provided a great con- tems is the need to balance on one side the high sensitivity of tribution to the improvement of the security of modern op- the information, and on the other hand the need for users to erating systems. A clear demonstration is represented by install into the system a large number of applications (called Android, which has progressively assigned a greater role to simply apps in this domain) often produced by unknown de- SELinux since its introduction in 2013. These benefits have velopers, which may hide malicious functions. A first level of been mostly dedicated to the protection of system compo- protection is offered, both in iOS and Android, by a prelimi- nents against the behavior of apps and no control is offered nary screening of apps before they are made available on the to app developers on the use of MAC. Our solution over- platform market [2] or installed to a device, but this approach comes this limitation, giving developers the power to define cannot provide a strong guarantee. Security mechanisms in- ad-hoc MAC policies for their apps, supporting the internal ternal to the operating system are needed in order to constrain compartmentalization of app components. the apps to only operate within the boundaries specified by This is a natural evolution of the security mechanisms al- the device owner at installation time. ready available in Android, but its realization requires to con- The approach used in the design of mobile operating sys- sider that (i) the security of system components must be main- tems considers as the first requirement the protection of sys- tained, (ii) the solution must be usable by developers, and tem resources. Focusing on Android, which is open source (iii) the performance impact should be limited. Our proposal and more accessible to researchers, we notice a significant evo- meets these three requirements. The proposal is supported by lution in its internal security architecture. This architecture is an open-source implementation. quite rich and consists of many security measures [44, 58]. In this environment, we specifically look at the role of SELinux. SELinux implements the Mandatory Access Control (MAC) 1 Introduction mechanism, which relies on a system-level policy to declare the operations that a process can execute over a resource Security in operating systems has greatly evolved and has based on the security labels associated with them. Compared been able to address many of the threats originating by an to classical Discretionary Access Control (DAC), still used extensive and varied collection of adversaries. in Android in an extensive way, MAC is more rigid and pro- The mitigation of security threats is particularly important vides stronger guarantees against unwanted behaviors. When for mobile operating systems, due to their wide deployment SELinux was introduced into Android 4.3 in 2013 (see Fig- and the confidential information they hold. ure1), it used a limited set of system domains and it was Both Android and iOS have seen significant investments mainly aimed at separating system resources from user apps. toward the realization of advanced security techniques, which In the next releases, the configuration of SELinux has progres- have led to a great increase in the level of protection offered to sively become more complex, with a growing set of domains users [58]. The strength of security and the value of protected isolating different services and resources, so that a bug or resources is testified, for instance, by the payouts associated vulnerability in some system component does not lead to a with working exploits in markets like Zerodium [72], where direct compromise of the whole system. the payouts for mobile operating systems are the highest1. The introduction of SELinux into Android has been a clear success. Unfortunately, the stronger protection benefits do ∗now at Google 1At the time of writing, US$2.5M and US$2M are paid for a zero click not extend to regular apps which are assigned with a single solution able to subvert the security of Androd and iOS, respectively. domain named untrusted_app. Since Android 9, isolation of apps has increased with the use of categories, which guar- app 1 app 2 app 1 app 2 app 1 app 2 app 1 app 2 antees that distinct apps operate on separate security contexts. Our proposal, SEApp, builds upon the observation that giving app developers the ability to apply MAC to the internal struc- ture of the app would provide more robust protection against other apps and internal vulnerabilities. system services system services system services system services 2 Android security for apps Before Android 4.3 - Since Our Android 4.3 Android 8 Android 9 Proposal One of the major requirements considered in the design of mobile operating systems is the need to constrain the ability Figure 1: Evolution of the MAC policy in Android. Before 4.3, of apps to manipulate the execution environment. Apps may MAC was not used. Starting with 4.3, MAC protects system hide functions that are meant to gain system privileges or components. Since 9, categories offer rigid MAC protection capture valuable information from other apps. Compared to for apps. Our proposal offers flexible MAC protection to apps. classical desktop operating systems, there is greater reliance on the use of apps to access resources or get services, with more attention paid to limit the ability of apps to operate in the MAC dictates which actions are allowed based on the secu- system. Advancements in this context can have an impact on rity policy defined by the system. Specifically, only actions ex- how security for applications is managed in other domains [1]. plicitly granted by the policy are permitted. To decide whether The basic principle adopted to manage the threat introduced to permit or deny an action, a set of policy rules concerning by apps is the design of a sandbox, a restricted environment the security contexts (i.e., collections of security labels that for app execution, where anomalous actions by the app are classify resources) of the involved parties is evaluated. not able to access resources beyond what has been authorized In Android, MAC is implemented using SEAndroid, a set at app installation time. The sandbox can be considered a of kernel modifications part of the Linux Security Module realization of the “least privilege” security principle. (LSM) framework [70]. Since its first introduction with the Se- The construction of the app sandbox is based on three curity Enhanced Android (SEAndroid) project [65], SELinux access control mechanisms: Android permissions [14, 44, 45], has been extensively applied to protect system components. Discretionary Access Control (DAC) [38], and Mandatory Initially, it was used to assert the security model requirements Access Control (MAC) [63]; each of them roughly aligning during compatibility testing, then its usage grew further at with how users, developers, and the platform grant consent, each release. In the current version Android 11, SELinux respectively. is also used to isolate the rendering of untrusted web con- Android permissions restrict access to sensitive data and tent (by the isolated_app domain), to restrict ioctl system services. In file AndroidManifest.xml [16], each app stat- calls [56], thus limiting the reachability of potential kernel ically lists the Android permissions needed to fully operate. vulnerabilities, and to support multi-user separation and app Not all of them may be granted; depending on the threat they sandboxing with SELinux categories. This last aspect permits pose from a security and privacy standpoint, they may be to enforce app separation both at DAC and MAC. Android granted as part of the installation procedure, or prompted to dynamically assigns categories to apps during app installa- the user when the app needs them. tion, so that: (i) an app running on behalf of a user cannot DAC restricts access to resources based on user and group read or write files created by the same app on behalf of an- identity. By assigning each application a unique UNIX user other user (since Android 6 [9]); and, (ii) an app cannot read ID (UID) and a dedicated directory, Android isolates apps or write files created by another app (since Android 9 [11]). from each other and from the system. However, UID sandbox- Before Android 9, this separation was only enforced at DAC ing has a number of shortcomings. As an example, processes level. This overlap of security measures is of extreme rele- running as root are not subject to these restrictions. For this vance to the enforcement of the Android Security Model and reason, when such a process is misbehaving, for instance due our proposal moves in the same direction. To bypass these to a bug, it can access private app data files. DAC discretion- protections, a process should be granted root permissions, ality itself is a problem. Indeed, as apps and system processes DAC_OVERRIDE or DAC_READ_SEARCH, and run as SELinux could override safe defaults, they are more susceptible to dan- mlstrustedsubject; only a few critical system services run gerous behavior, such as leaking files or data across security in this configuration. boundaries via IPC or fork/exec. Despite its deficiencies, UID Android restricts the SELinux implementation to the policy sandboxing is still the primary enforcement mechanism that enforcement, ignoring most policy management functions.