This chapter described a feature vector-based approach to studying and understanding access controls in Android. The method was used to develop an interactive database of access controls in the System Services of 19 Android images. Seven of these are AOSP images and are used as a baseline in a case study to analyze the changes introduced by the vendors of the other 12. This differential analysis is captured in a second interactive database. Selected changes from three of
the vendor images were further studied on actual devices, in order to confirm the feature vector data, its utility and show that the methodology can be used practically to find potential
shortcomings in vendor customizations. The case study revealed a number of issues and inconsistencies with the vendor code.
Chapter 5
Protecting Sensitive and Vulnerable Resources
Traditionally, we’ve thought about security and usability as a trade-off: a more secure system is less functional and more annoying, and a more capable, flexible, and powerful system is less secure. This “either/or” thinking results in systems that are neither usable nor secure.
- Bruce Schneier
Chapters3and4describe security analysis methodologies that provide insights into the inner workings of Android access controls, in both open source and vendor implementations. As the results show, the advantages of an open, modular system, whereby each resource is responsible for implementing its own access controls, can be offset by security problems arising from
mistakes and inconsistencies. In particular, protections implemented by resources can be partially or completely nullified when changes to the platform architecture or vendor customizations invalidate the assumptions implicit in the original design. To address these situations, each and every resource must be reevaluated and redesigned every time the platform changes. If system designers and vendors use the methodologies of the previous chapters, then these mistakes can be fixed before the platform is deployed. However, once deployed, end-users have virtually no way of addressing any remaining problems unless the platform itself contains a flexible, generic means of isolating any vulnerable resource(s) from untrusted apps.
Many of the system insights gained during the course of work described in earlier chapters relate to the mechanisms by which Android’s modular system resources are requested, protected, and accessed. The knowledge gained from the systematic, top-down subject-object access control path evaluation, combined with that from the detailed method-level feature vector-based
characterization and comparison led to new insights. These led to the realization that almost any current or future system resource could be transparently isolated from apps that may take advantage of access control shortcomings or, for critical apps, fall victim to poorly designed or malicious resources. This chapter describes the concept and design methodology that emerged from these realizations, and demonstrates through an actual implementation and case study how the novel approach is simultaneously efficient, effective, and consistent with Android’s unique architecture and design tenets.
5.1
Introduction
Security and privacy compromises by malware and faulty apps is a persistent concern of smartphone users. While many users may not fully understand the technical aspects of security architectures, permissions, access control mechanisms, or measuring trust, most have no trouble articulating which high level objects, resources or capabilities they are most concerned with. For example, it’s common to find users worried about how apps might misuse or leak their location, sensitive data such as personal contacts, or personally-identifiable information (PII) like phone number and International Mobile Station Equipment Identity (IMEI). In response to this, numerous solutions to address these concerns have been proposed, and many of these involve some form of virtualization combined with access control to isolate untrusted applications.
Although every approach to isolation has its own unique strengths and weaknesses, all include trade-offs in terms of sharing and communication. In Android’s open architecture, where resource sharing and inter-process communication (IPC) are fundamental to the platform’s basic operation and usability, careful attention must be paid to fully understanding how a particular isolation
boundary impacts the system’s functionality and performance. If this trade-off is not considered at the outset of a design, significant performance, usability, and functionality issues can arise. Countering these negative side-effects requires designers to overcome challenging system problems, typically resulting in substantial modifications to the operating system, and significant second-order complexities not directly related to the initial security goals. These problems are especially prevalent in general-purpose designs that attempt to provide isolation containers for entire apps or virtual phones, without the benefit of a priori knowledge of specific threat(s) or end-user security goals.
This chapter introduces PINPOINT, a resource isolation strategy that forgoes general-purpose solutions in favor of a lightweight approach that addresses only specific end-user security goals. By addressing the end-users’ stated security goals and no more, PINPOINT yields an effective result using only the minimum amount of isolation. This significantly reduces or even eliminates the negative side-effects that inevitably emerge when large parts of Android’s open, shared architecture are isolated. Because isolation of resources can occur at many places within the system architecture, and with varying degrees of granularity, the chapter begins with a discussion of the tradeoffs in the design space in Section5.2. This is followed by Section5.3, which contains a high-level description of the chosen concept. Section5.4describes a case study whereby we implemented the PINPOINT concept as a lightweight hypovisor1within Android’s Context Manager, facilitating isolation of any System Service. Since resources available to apps are
typically presented as System Services, this case study implementation addresses a wide range of practical security and privacy problems.