附录Y 外文原文

Application-centric security policies on unmodified

Android

Googlersquo;s Android platform uses a fairly standard resource-centric permission model to protect resources such as the camera, GPS, and Internet connection. We claim that a much bet-ter permission model for developers and users would be application-centric, with a vocabulary that directly relates to application-level functionality, e.g., one permission could allow camera use, but only for barcode scanning; another could allow Internet access, but only to certain do-mains. Despite the large apparent gap between resource- and application-centric permissions, we argue that Android already provides the necessary mechanisms to support an expressive and practical form of application-centric policies. Specifically, each application-centric per-mission can be represented by a new Android permission and can be enforced by coupling the permission with a trusted service running in its own process. We present a survey of the top 24 free Android apps and show that a small vocabulary of application-centric permissions covers much of the functionality of those apps. We also describe a prototype implementation of our approach.

1.Overview

Googlersquo;s Android is one of the most popular smartphone platforms, with more than 100 million activated devices, more than 200,000 applications in the Android Market, and an estimated 4.5 bil-lion apps installed from the Market. Security of Android applications (henceforth “apps”) is a pressing concern, as apps can collect sensitive data from the user (e.g., usernames and passwords), access personal data stored on the device (e.g., calendar and contact information), and use sensitive device capabilities (e.g., telephony, GPS, and camera).

Android takes an “open-publish” approach to app distribution, in which any app can be installed on any phone. To help address security concerns, the Android platform protects access to sensitive resources—including the camera, network sockets, and GPS receiver—with permissions. Each app includes an XML manifest file that lists the permissions requested by the app. When an app is installed, those permissions are shown to the user, who then decides whether or not to proceed with the installation. No additional permissions may be acquired when an app runs, and a security exception is raised if an app tries to access a resource without permission.

In our view, the basic problem with Androidrsquo;s permission system is that it is resource-centric: each permission typically controls access to a particular hardware or software resource. Thus, enforceable security policies only say what resources are accessed, with little or no indication ofApplication-centric permissions on unmodified Android. There are two major challenges that any solution to this issue must address: First, Android is evolving rapidly, with new hardware and software capabilities emerging regularly, and thus any solution must be agile and adaptable. Second, the permissions required by apps must capture application-centric security properties that are intuitively understandable to both developers and users.

It is tempting to try to address this problem by enriching Androidrsquo;s permission system in vari-ous ways. For example, each existing permission could be sliced into smaller permissions granting rights to correspondingly finer units of resource access. As another example, an applicationrsquo;s manifest could use an authorization language (e.g., DCC or KeyNote) to establish constraints on resource access. A program analysis or type system (e.g., JIF) could also be used to track how in-formation flows through an app. However, we believe such approaches require making important architectural commitments up-front, and they may be difficult to evolve on such a rapidly changing platform. Furthermore, it is imperative that the policy language be kept simple for developers and users alike.

Perhaps surprisingly, we believe that Android already contains the key ingredients needed for a powerful and practical solution to the above challenges: interprocess communication, process iso-lation, and user-defined permissions. Interprocess communication enables an application to access rich functionality provided by trusted third parties. Process isolation ensures that applications only access that functionality through a well-defined interface, thereby allowing third parties to enforce arbitrarily expressive application-centric security policies. Finally, user-defined permissions allow these policies to be associated with simple Android permissions that applications must acquire to access the desired functionality.

Consider again the problem of supporting safe barcode scanning. An ideal security policy would specify that the camera may only be used to scan a barcode, and the resulting images are thrown away after processing. We propose to represent this policy as a new Android permission, ScanBarcodes, that grants access to a trusted library that obeys the policy. To do so, the library could have a single function that displays the current camera image, waits for a user click, and then scans the resulting image for a barcode, and returns the barcodersquo;s numerical value to the calling app. Furthermore, we can implement the library as an Android service that runs in a separate process. Therefore, while the library must be granted full camera access, an app that calls into the library need only be granted ScanBarcodes access, thereby providing a strong and understandable guarantee to both the app developer and users.

Although at first glance it seems we may need many such application-centric permissions, our hypothesis is that in practice a reasonably small set can dramatically improve the security of a wide variety of applications. Moreover, we envision an ecosyst

剩余内容已隐藏，支付完成后下载完整资料

英语译文共 25 页，剩余内容已隐藏，支付完成后下载完整资料

资料编号：[484659]，资料为PDF文档或Word文档，PDF文档可免费转换为Word