Removal

When apps are uninstalled, the assigned uid is freed up for reuse and its data directories are removed. In some cases, remnants of the installation persist, such as credentials, capabilities, settings, history, etc., and may cause security problems [29]. This continues to be an active research area.

Chapter 3

Android Access Control Evaluation

Methodology

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards.

- Gene Spafford

The Android operating system is rapidly evolving, with major releases now occurring

approximately every six months. Each of these releases contain new features, enhancements, and refinements that have significant security implications. These implications must be understood, especially when devices are employed for critical and sensitive applications or in adversarial environments. Unfortunately, Android is a very complex system, and as explained in Chapter2, its security architecture has been designed as an open system whereby access controls are placed as close to the corresponding resource as possible. In this architecture, access control policy and implementation are the responsibility of the resource itself. While this modular approach makes adding new or unique resources easier, evaluating the soundness of platform-wide changes as they relate to every resource becomes very difficult because of the many access control points involved.

This chapter introduces a methodology for modeling, discovering and evaluating access controls in Android. It is especially well-suited to evaluating how platform-wide architectural changes or feature additions impact the security of the many separate resources whose access controls may have been designed under earlier, potentially invalidated assumptions. The chapter also

describes the results from a case study which demonstrates the effectiveness of the method. The case study applied the method to evaluating the security of Android’s multi-user framework, a significant platform change which was first introduced in the 2012-2013 time-frame. The multi-user extensions to Android represent exactly the kind of platform change that results in security

problems involving resources previously designed under assumptions invalidated by the change.

3.1

Introduction

The impressive growth of Android includes not only the number of traditional smartphone devices running it, but an expansion to other “keyboardless” and embedded devices such as tablets, home entertainment equipment, automobile dashboards, and home appliances. While the typical smartphone is a personal single-user devices, many of the others are intended for use by several individuals. Thus, one major driving force behind the features included in recent releases of Android is the need for multi-user support, which has grown along with its expansion from strictly personal devices to those with varied purposes in multi-user environments. Today, the vast majority of fielded Android devices are multi-user capable, with Google Dashboards reporting in June 2016 that 89.2% of active devices were running a multi-user-capable version [30] (up from 27% in 2014).

Multi-user features take two different forms in Android: Multiple Users (MU), introduced in version 4.2 (API 17) in November 2012, and Restricted Profiles (RP), introduced in version 4.3 (API 18) in July 2013. With each subsequent release, the multi-user functionality was refined and expanded to fit other contexts such as corporate environments.1Targeted towards sharable devices such as

tablets, these enhancements strive to provide individual, isolated user spaces on a single physical device. Each user space supports a separate set of accounts, apps, settings, files, and user data, distinct from those of the primary owner [32], however there are slight differences in the

functionality they provide.

Multiple Users (MU) designates the main account as Owner. Through the device settings, the owner account may create additional MU accounts. These secondary accounts are

essentially the same as the owner, except for the fact that they cannot manage (i.e., create, modify, delete) other users. MU accounts enjoy most of the other privileges and

functionality of the owner, including managing the device’s wireless and network settings, pairing Bluetooth devices, customizing sound and display settings, installing/removing their own apps, adjusting privacy settings (e.g., location access), and configuring security features (e.g., screen lock, credentials). Each account also has a separate virtual SD card storage area within the physical SD card.

Restricted Profiles (RP) are similar to MU accounts, but they lack several key functionalities

compared to owner and MU accounts. Like MU accounts, RP accounts cannot manage users. In addition, RP accounts are restricted from installing apps. Instead, the owner account “turns on” specific apps from the set of installed apps for the RP account.

A reasonable layperson might assume that these enhancements would provide user and profile isolation similar to that provided by today’s desktop multi-user systems. However, end-users working with multi-user features immediately encounter warning signs that this may not be the case. When creating new users on a device, two telling confirmation dialogs appear as shown in Figure3.1. The dialog shown in Figure3.1awarns that “any user can update apps for all other users”, while that of Figure3.1bimplores the new user to “only share this phone with people you trust”.

managed apps to coexist with personal apps in the same user account and launcher. My own brief investigation [31] revealed that the underlying technical implementation of Managed Provisioning is very similar to that described here for Multiple Users and Restricted Profiles. As such, many of the security concerns outlined here are applicable to Man- aged Provisioning.

(a) Warning to device owner. (b) Warning to new user.

Figure 3.1: Warning messages encountered while creating additional user accounts. To security-minded individuals, these kinds of warnings raise red flags. Combined with the fact that multi-user features were basically “bolted on” to an existing design, and the obvious security implications of multi-user features for any system, there is plenty of reason to worry about the soundness of these new capabilities. In fact, Android’s evolution towards a multi-user system is not unlike that which happened with Microsoft’s Windows operating systems in the 1990s, which started out as a single-user system. Compared to Unix, which was designed from the outset with multiple users in mind, Windows’ later inclusion of these features was much more problematic in terms of security [33]. Thus, is important to assess whether Android’s new multi-user framework accounts for the fact that the single-user assumption of the original design has been invalidated, as Microsoft arguably failed to do with initial multi-user versions of Windows.

However, rather than conducting an evaluation specific to the multi-user framework, this work contributes a systematic access control evaluation methodology that is tailored to the unique characteristics of Android, but generic enough to be suitable for use in evaluating any aspect of the system’s access controls. The method enables one to gain security (and vulnerability) insights, which then lead to hypotheses about potential security problems. These hypotheses can be

tested by way of focused experimentation. The efficacy of the method is proven via a case study on Android’s multi-user framework, a recent, security-related addition to the system, which had not been studied before.2