Discussion

Performance evaluation results presented in Section5.6indicate that increasing numbers of PINPOINTed services has a negligible effect on CPU, browser, and graphics performance. On the other hand, data indicates a clear correlation between the number of PINPOINTed services and file I/O. Decreases in this score with increasing numbers of namespaces is expected due to an increase in policy file size and associated data structures being parsed and searched by servicemanager during every service lookup request in order to support namespace

by an average of 1.57% of the 0NS value for each additional namespace represented in the policy file. Although this degradation is negligible for simple policy files, we feel that this is an area for improvement. Future implementations will include an optimization of this code, and policy options to configure how often policy lookups are performed.

We also observed a growth in system_server’s memory size that is correlated to the the number of additional service objects (i.e., namespaces) available for use in the system_server process. On average, we observed this increase to be approximately 0.64% of the 0NS value per each additional service. For a system with one additional IMEI namespace, two additional location namespaces, one additional input method namespace, and two additional sensor namespaces, system_server would have an approximately 3.84% larger memory footprint than the stock process. Note that an unused namespace still consumes additional memory, but since it does not add to the policy file, it will not contribute to file I/O degradation. This is another area target for improvement in the future.

5.7

Future Directions

In our present work, we have gained a tremendous insight into the trade-off between isolation design alternatives, system complexity, usability, convenience and effectiveness. We plan to further quantify these relationships so that we can make informed choices when addressing the high-level requirements typically stated by end-users. Ultimately, we plan to formalize the PINPOINT methodology, so that security designers can easily understand the trade space of PINPOINT designs vs. general-purpose approaches.

Through our case study of implementing a services hypovisor, we’ve acquired a sense for the difficulty of implementing a representative PINPOINT hypovisor and its companion virtual

resources within the Android Framework. Encouraged by our experiences, we plan to consider the potential benefits of PINPOINTing other resources, including those outside the purview of Service

Manager. Following from this, we envision implementing a container abstraction, whereby multiple, heterogeneous PINPOINTs, Linux Namespaces, and other forms of access control and virtualization can be easily combined by the end-user to form easily-understood security and privacy macros such as “incognito,” “banking,” etc.

We recognize the inflexibility of having to define PINPOINTed resources at system build time. As such, we see opportunities to investigate techniques for establishing new PINPOINTs while the system is running. Also, we would like to evolve our current rudimentary means of policy

configuration into a more powerful and intuitive means for end-users to configure, combine and use PINPOINTed resources, possibly through an advanced launcher interface.

Additional project details, status, and instructions for requesting access to our prototype code are available at https://goo.gl/2pJeMp.

Chapter 6

Related work

This chapter is organized as follows: Section6.1discusses previous work on security analysis techniques and specific types security and privacy problems in Android, and compares these with the contributions of Chapters3and4. Section6.2compares the contributions of Chapter5with prior work on resource protection, sensitive data protection, and privacy.

6.1

Security Analysis

Work on systematic security analysis was initially inspired by those who have reported on confused deputies [89], [90], [91], [92], [93], [94], component hijacking [95], and capability leaks [41], [96] in Android. However, these are different from the work presented here for two reasons. First, their goal is to find and explain specific types of vulnerabilities rather than gaining an overall understanding of how access control is implemented along paths between specific sets of

subjects and objects (Chapter3), or within the modular resources themselves (Chapter4). When subject-object paths are checked, both effective as well as missing or ineffective access controls are uncovered. These missing or ineffective controls may lead to one or more of the categories studied in the previous work, but new categories are also uncovered because of the deliberate choice to focus on subject-object combinations rather than a specific threat model.

Second, the contributions of Chapters3and4include unique case studies that result in findings different than previous work. The case study on the multiuser framework was described by a reviewer as the only known at the time of publication, and this still appears to be the case at the time of this writing. In fact, a fundamental difference is that that all of the previous work focuses on maliciousness among or by apps, while the multiuser work addresses potential maliciousness among users. Several studies [97,98], [99], [100] have explored the use of motion sensors available on smartphones to perform user activity recognition, while [22], [24], [23], [82], [25] have focused on inferring user keyboard presses, icon taps and secure inputs using accelerometer and

gyroscope sensor. Nonetheless, these do not consider unauthorized use of these sensors by other users of the device as done here. Finally, [101] and [102] present complete secure multi-user architectures which may be able to solve some of the problems identified in Chapter4.

Several works have contributed to finding security flaws and inconsistencies in Android. Kratos [47] uses static analysis to find access control inconsistencies in System Services. The authors define these as any condition where two entry points from the same image reach the same sink by different paths, and the security checks along the two paths differ. As such, Kratos cannot find missing access controls, or evaluate controls against special conditions such as user switching, as Chapter3’s methodology does. In addition, Kratos does not allow comparisons among different images, as is the case with the differential feature-based analysis of Chapter4. Finally, Kratos depends on costly static analysis of the entire code path between entry point and resource, in contrast to the feature-based approach which favors rapid analysis as well as creation of a comprehensive feature database that can support a variety of research inquiries.

Identification and evaluation of custom system configurations, including the addition of receivers and custom permissions by device vendors is the subject of [46]. The authors extract features from system and app manifests and compare these to a baseline. Although similar in terms of the feature-based approach of Chapter4, the actual feature sets are quite different, as are the feature extraction processes and portions of the system that are evaluated. Hence, the prior work and the

work presented herein are complementary.

Problems with pre-loaded apps are addressed in several works [44,41,45]. As is the case with the custom configuration work just discussed, these evaluations focus on the apps and their

configurations rather than the system code itself.

Hanging attributes are unused references that can be co-opted by malicious apps. [43] describes a means to identify these in custom system images. At a high level, this is essentially a special case of the feature extraction introduced in Chapter4. However, the goal of Chapter4is to generate an overall characterization of access controls to support a variety of inquiries, while this work is specialized in identifying only hanging attributes. Nevertheless, the two contributions are complementary in that they each provide important assessments of security within the system itself.

The Linux kernel has been the subject of security analysis for many years. In 2000, [48] introduced an automated compiler-based method that finds system-specific rule violations in source code. Certain features of compiler error output are examined and matched against a set of rules designed to find security problems and other bugs. At a conceptual level, the features generated by the compiler extensions have several similarities to the features described in Section4.2.1. Each are defined from domain knowledge through a feature engineering process. Each attempts to capture salient information about the system in an efficient albeit lossy representation. Finally, each is used to facilitate additional analyses necessary to make various conclusions about the system. However, in addition to the obvious differences between the Linux kernel and Android Framework, which make the feature sets entirely incompatible, the features of [48] are specific to finding particular bugs rather than providing a more general characterization of access controls as described in Chapter4. In addition, the compiler-based approach requires source code, while the extraction process described in Section4.2.2is useful for proprietary vendor devices for which source code is not available.

Chou et al. and later Palix et al. used this compiler-based methodology to answer questions about the nature of bugs in the Linux kernel [49,50]. They studied the location of bugs across different subsections of the kernel, bug distribution properties, and bug clustering. At a high-level, this type of analyses and characterization is similar to how the feature vectors are used in Section4.2to study the nature of various Android System Services. They also performed differential analysis among different kernel versions to learn how long bugs live in a particular kernel and how different kernels (e.g., OpenBSD vs Linux) compare. Again, at a high level, this is similar to the vendor comparison discussed in Section4.3. Thus, the feature database described in Section4.4

could be used to answer similar questions about the Android codebase in future work.

Zombie features are kernel features which cannot be enabled or disabled at all because of inconsistencies between the kernel implementation and its representation in the configuration tool. [51] extracts features from C preprocessor blocks in kernel source and compares them with a corresponding model generated from the kernel configuration tool to identify inconsistencies and find zombie features. [52] maps configuration options to related source code files, enabling identification of sources affected by a change to configuration options. Both of these techniques could be applied to Android’s Linux kernel, and the results would complement the various Framework analyses described here.

6.2

Resource Protection

A number of previous efforts have addressed the problem of untrusted apps having access to sensitive or private information. Some of these address specific types of data, such as location, while others look for more general solutions. These works can be classified into broad categories of inspection, permissions, and isolation.

Approaches using inspection, including IPC Inspection [76], Quire [92] and TaintDroid [103], have provided more access control and tracking of call chains, IPC messages, and information flows,

respectively. Although these may identify or prevent privilege escalation and confused deputy attacks among apps, they do not address an app’s direct access to resources it already has adequate permissions for, as PINPOINT does. While TaintDroid can identify restricted information flows, it has no provisions for preventing them.

AppFence [104] leverages TaintDroid monitoring to enable data substitution and blocking. For information resources, such as location and IMEI, the resulting capability is similar to some of PINPOINT’s basic namespaces. However, AppFence cannot control the semantics of functional resources, such as we demonstrated with the input method namespace. Furthermore, AppFence’s substitution and blocking capabilities affect information resources for the entire platform rather than being selective for individual apps as is the case in the System Services case study.

Mr. Hide [105] added finer-grained permissions to apps by way of byte code rewriting, while APEX [106] introduced context-sensitive run-time permissions. Compac [107] allows different

components within apps, such as in-app ads, to have different sets of permissions. The work of Chapter5and other isolation approaches are fundamentally different from these, as the previous work strives to enhance inadequate access control mechanisms, while isolation approaches use virtualization to place untrusted apps in containers where sensitive or vulnerable resources are simply not present, or exist with redefined semantics.

Previous work in the area of isolation includes MOSES [108], a framework designed to isolate applications and data for the purpose of protecting sensitive corporate data. While MOSES represents an effective general solution to securing corporate data leaks on mixed-use

personal/business devices, it is not very suitable for protecting users’ privacy or securing specific resources because of its security profile-centric architecture that forces explicit switching and carries performance penalties.

Two significant isolation approaches that influenced the PINPOINT effort tremendously are Cells[65] and AirBag [64]. Cells leverages Linux Namespaces to allow multiple Android user spaces

to run simultaneously on a single hardware platform. Each user space, or virtual phone (VP), is isolated in a combination of separate Linux Namespaces for file system paths (mount namespace), process identifiers (pid namespace), IPC identifiers (System V IPC namespace), network interface names (network namespace), user names (userid namespace), and hardware devices (a new Linux namespace introduced in the work). Cells introduces the concept of a foreground and multiple background phones that are isolated from each other so that malicious or buggy apps in one VP cannot affect others. Isolation in Cells is thus achieved at the virtual phone boundary.

AirBag also leverages Linux Namespaces, but achieves isolation at the native runtime boundary. This is accomplished by instantiating a separate app runtime that has virtually no interaction with the original native runtime. Each isolated runtime contains its own copies of key service processes and daemons, such as vold, binder and servicemanager that are launched in separate

namespaces as compared with the normal runtime. Thus, an untrusted app “sees” an entirely different set of services, binder objects, file paths, etc. through the lens of its decoupled runtime. The untrusted app cannot communicate with apps in different runtimes, and the system resources it can view and control are completely dictated by the isolated runtime. Condroid[109] improves on AirBag’s design by restoring binder communications via virtual binders and increasing

efficiency by enabling many System Services to be shared among runtimes instead of duplicated.

While Cells, Airbag and Condroid provide excellent general-purpose isolation, their designs are complex, burden the system, and somewhat intrusive from the user’s point of view. For example, all three require special modifications to numerous shared hardware drivers, duplication of system processes and resources not related to the security goals, and introduce significant usability restrictions. Although they leverage lightweight Linux Namespace isolation, key benefits of Namespaces (Table5.2) are lost when the Android Framework is added on top since many fundamental aspects of Android’s open design are broken by the kernel-level isolation. Fixing these problems greatly complicates the designs. Thus, PINPOINT’s main difference from these works is the deliberate choice not to provide a general-purpose solution, but rather one that

addresses specific security goals by directly isolating the specific Framework objects associated with the security goals. For these specific cases, PINPOINT is simpler, less burdensome, and more usable.

Finally, as location data is widely viewed as having serious privacy implications, there are

numerous works specific to improving location privacy. LP-Guardian [110], LISA [111], and Koi [112] are examples of these. While each is effective for controlling or preventing the use of location data, they are not generally applicable to other resources as PINPOINT is. As the case study on

PINPOINTing System Services demonstrates, if the point of virtualization is chosen wisely, the resulting isolation capability is flexible enough to apply to classes of resources rather than only specific ones as these works do.

Chapter 7

Conclusion

Understanding a system’s design tenets and use cases, as well as its security architecture and implementation details, are important prerequisites to proposing useful improvements and making sound modifications. In the case of Android, its unique open architecture, emphasis on usability, and scattered access control points make it very different from previously-seen systems. In spite of its open source roots, gaining an understanding of Android security is difficult because of the sheer complexity of the code base, as well as the fact that most Android devices in use run customized, proprietary versions of the platform.

This dissertation introduces a simplified model of access control that can be used to

systematically analyze and understand access controls as they relate to different aspects of the system. The systematic process was used in the first and only evaluation of Android’s multiuser framework. This comprehensive evaluation uncovered a diversity of issues with the framework, from simple access control omissions to pervasive problems calling into doubt the suitability of the original architecture for supporting multiple users.

Although a labor-intensive manual investigation such as the one applied to the multiuser

framework may be fruitful, it is hardly suited to rapid assessment of the new Android versions that appear every few months, or the plethora of custom, closed-source images that are constantly surfacing. Thus, the next part of the dissertation contributes an access control feature extraction

technique which automates the characterization by way of static analysis libraries and database techniques. Unlike other static analysis-based approaches, which typically slice the problem in order to achieve great accuracy within a limited scope, the approach here trades off accuracy in favor of a broad scope that can encompass entire subsystems of many images in a relatively short time. The technique was applied in a case study of System Services from 19 real-world system images. The resulting database of over 35,000 methods represents an interactive resource that can be used to quickly identify and isolate problematic areas of a service or in vendor

customizations. The efficacy of the feature vector approach was demonstrated in a case study that identified a number of real vulnerabilities and inconsistencies in actual images. It is hoped that this database can be used by system designers as well as vendors to identify problems before new images are released to users.

Finally, the insights gained enabled the development of a novel means to employ virtualization and isolation to solve the problem of protecting sensitive resources and vulnerable services from untrusted apps, while not diminishing Android’s open design and strong emphasis on usability and performance. Known as PINPOINT, the hypovisor-based solution isolates only the minimum necessary objects in order to achieve stated security goals. As a new system framework feature, it allows problems not directly fixable by end-users, such as those mentioned above, to be

addressed in a flexible, lightweight way, without sacrificing usability or performance. The prototype demonstrated the effectiveness of the solution with a case study on four System Services.

Appendix A

Android Security Statements

TableA.1contains the results of a manual parsing of Android documentation to extract

security-related statements. These statements were one of several sources that formed the basis for the access control analysis described in Section4.2. The following documents were included (index corresponds to entries in “source index” column of table):

• 1.1: Security overview [113]

• 1.2: System and kernel security [114] • 1.3: Application security [115]

• 1.4: Security updates and resources [116] • 1.5: Security enhancements in Android 5.0 [117] • 1.6: Security enhancements in Android 4.4 [118] • 1.7: Security enhancements in Android 4.3 [119] • 1.8: Security enhancements in Android 4.2 [120]

Table A.1: Andr oid security st at ements. F e a tur e / spec Sour ce inde x Objec t Enf or cement