英语原文共 11 页
Android权限启发
Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, David Wagner
University of California, Berkeley
{ apf, emc, sch, dawnsong, daw }@ cs.berkeley.edu
摘要
Android为第三方应用程序提供了广泛的API，包括访问电话硬件、设置和用户数据。使用安装时应用程序许可系统控制对API的隐私和安全相关部分的访问。我们研究Android应用程序，以确定Android开发人员的权限请求是否遵循最少的特权。我们构建了Stowaway，这是一个在已编译的Android应用程序中检测过度特权的工具。Stowaway确定应用程序使用的API调用集，然后将这些API调用映射到权限。为了构建检测overpriv- ilege所需的权限映射，我们在Android API上使用了自动匹配的测试工具。我们将Stowaway应用到一组940个应用程序中，发现约有三分之一的应用程序具有过度特权。我们调查了过度特权的原因，并发现开发人员试图遵循最少特权的证据，但有时由于API文档不足而失败。
关键字：Android，权限，最少的特权
介绍
Android不受限制的应用市场和开源使得它成为第三方应用程序的流行平台。截至2011年，Android Market包含的应用程序比苹果应用商店[10]还多。Android支持第三方开发，它提供了广泛的API，可以访问手机硬件(如摄像头)、WiFi和蜂窝网络、用户数据和手机设置。
访问Android富API的隐私和安全相关部分是由安装时应用程序许可系统控制的。每个应用程序必须预先声明它需要什么权限，并在安装过程中通知用户它将获得什么权限。如果用户不想授予应用程序权限，他或她可以取消安装过程。
安装时权限可以为用户提供对其隐私的控制，并减少应用程序中的bug和vul- nerability的影响。然而，如果开发人员经常要求比他们需要的更多的权限，那么每个任务的安装时系统是无效的。特权过大的应用程序会向用户暴露不必要的权限警告，并增加bug或漏洞的影响。我们研究了一个- droid应用程序，以确定Android开发人员遵循的是最少特权还是过多特权他们的应用程序。
我们提供了一个名为Stowaway的工具，它可以检测编译后的Android应用程序中的过度特权。Stowaway由两部分组成:一个静态分析工具，确定应用程序调用什么API;一个权限映射，确定每个API调用需要什么权限。droid的文档没有为这样的分析提供足够的权限信息，因此我们从经验上阻止了Android 2.2的访问控制策略。使用自动化测试技术，我们实现了Android API 85%的覆盖率。我们的权限映射提供了对Android权限系统的深入了解，并使我们能够识别超权限。
我们将Stowaway应用于来自Android市场的940个Android应用程序，发现大约三分之一的应用程序被滥用了特权。特权过大的应用程序通常要求很少的额外特权:超过一半的应用程序只包含一个额外的权限，只有6%的应用程序请求超过四个不必要的权限。我们研究了过度特权的原因，发现许多开发人员错误源于对权限系统的混淆。我们的结果表明，开发人员正试图遵循最少的特权，这支持了像Android这样的按任务安装系统的潜在效率。
Android提供开发人员文档，但是它的每个任务的信息是有限的。缺乏可靠的任务信息可能会导致开发人员出错。doc- umentation只列出了78种冰毒ods的许可要求，而我们的测试显示了1,259种方法的许可要求(比docu-提高了16倍)。此外，我们在Android权限文档中确定了6个错误。这种不精确性使得开发人员可以用猜测和mes- sage板来补充参考资料。开发人员的困惑可能导致特权过大的应用程序，因为开发人员添加了不必要的权限，试图使应用程序正确工作。
我们的贡献如下:
- 我们开发了Stowaway，一个在Android应用程序中检测overpriv- ilege的工具。我们用Stowaway软件对Android市场上的940个应用程序进行了评估，发现大约三分之一的应用程序被滥用了特权。
- 我们识别并量化导致过度特权的开发人员错误模式。
- 使用自动化测试技术，我们确定了一个- droid的访问控制策略。我们的结果比文档显示了15倍的改进。
其他现有的工具[11,12]和未来的程序分析可以利用我们的权限地图来研究Android应用程序中的权限使用情况。Stowaway和permission地图数据可以在android-permissions.org上找到来源。第2节概述了Android及其许可系统，第3节讨论了我们的API测试方法，第4节描述了我们对Android API的分析。第5节描述了用于检测超权限的静态分析工具，第6节讨论了应用程序超权限分析。
ANDROID权限系统
Android拥有广泛的API和权限系统。我们首先提供Android应用程序平台和权限的高级概述。然后，我们将详细介绍Android权限是如何执行的。
2.1 android背景
Android智能手机用户可以通过Android Market[3]或Amazon App store[1]安装第三方应用程序。这些第三方应用程序的质量和可靠性差别很大，因此Android将所有应用程序都视为潜在的bug或恶意应用程序。每个应用程序在一个进程中以低权限用户ID运行，默认情况下应用程序只能访问它们自己的文件。应用程序是用Java编写的(可能还附带原生代码)，每个应用程序都在自己的虚拟机中运行。
Android使用安装时权限控制对系统资源的访问。Android 2.2定义了134个权限，cat- egorized为三个威胁级别:
1.正常权限保护对API调用的访问，这些调用可能会惹恼用户，但不会伤害用户。例如，SET_WALLPAPER控件更改用户背景墙纸的功能。
2.危险权限控制对潜在有害API调用的访问，比如那些与花钱或收集私人信息相关的调用。例如，发送文本消息或读取联系人列表需要Dan- gerous权限。
3.签名/系统权限控制对最危险特权的访问，例如控制备份进程或删除应用程序包的能力。这些权限很难获得:Sig- nature权限只授予使用设备制造商的认证签名的应用程序，而SignatureOrSystem权限授予已签名或安装在spe- cial系统文件夹中的应用程序。这些限制实质上将签名/系统权限限制为预先安装的应用程序，其他应用程序对签名/系统权限的请求将被忽略。
应用程序可以为自我保护定义自己的权限，但是我们主要关注android定义的每个任务来保护系统资源。我们在分析的任何阶段都不考虑开发人员定义的权限。类似地，我们不考虑Google定义的权限，这些权限包含在谷歌应用程序(如谷歌Reader)中，但不属于操作系统的一部分。
在与系统API、数据库和消息传递系统交互时，可能需要权限。公共API[2]描述了8,648个方法，其中一些方法受权限保护。用户数据存储在Con- tent提供程序中，对某些系统内容提供程序的操作需要权限。例如，应用程序必须持有READ_CONTACTS权限，以便在Contacts内容提供程序上执行读查询。应用程序也可能需要权限来接收意图(即，消息)来自操作系统。意图通知应用程序事件，例如网络连接的变化，并且系统发送的一些意图只交付给具有适当权限的应用程序。此外，发送模拟系统意图内容的意图需要权限。
2.2许可实施
我们将描述如何实现和保护系统API、内容提供者和意图。据我们所知，我们是第一个详细描述Android权限执行机制。
2.2.1 API
API结构。Android API框架由两部分组成:驻留在每个应用程序的虚拟机中的库和在系统进程(es)中运行的API的实现。API库以与应用程序相同的权限运行，而系统进程中的API实现没有限制。库为与API实现交互提供了语法糖。读取或更改全局电话状态的API调用由库代理到系统进程中的API im- plementation。
API调用分三步处理(图1)。首先，应用程序调用库中的公共API。其次，库调用一个私有接口，也在库中调用。私有接口是RPC存根。第三，RPC存根使用要求系统服务执行所需操作的系统流程启动RPC请求。例如，如果应用程序调用ClipboardManager.getText()，该调用将中继到IClipboard$Stub$Proxy，后者代理对系统进程的ClipboardService的调用。应用程序可以使用Java反射[19]访问API库的所有隐藏和私有类、方法和字段。一些专用接口没有相应的公共API;但是，应用程序仍然可以使用反射调用它们。这些非公共库方法用于谷歌应用程序或框架本身，建议开发人员不要使用它们，因为它们可能在[17]版本之间更改或消失。尽管如此，一些应用程序使用它们。Java代码运行在一个独立的虚拟机和系统进程中，因此不受反射的影响。
为了执行权限，系统的各个部分调用权限验证机制来检查给定的应用程序是否具有指定的权限。权限验证机制是作为可信系统过程的一部分实现的，permis- sion验证机制的调用在整个API中传播。当调用API时，没有检查权限的集中策略。相反，中介取决于权限验证调用的cor- rect位置。
权限检查放在系统流程的API实现中。必要时，API实现调用权限验证机制来检查调用的应用程序是否具有必要的权限。在某些情况下，API库还可能冗余地检查这些权限，但是不能依赖这些检查:应用程序可以通过RPC存根直接与系统进程通信来绕过这些检查。因此，不应该在API库中进行权限检查。相反，系统流程中的API实现应该调用权限验证机制。
少数权限由Unix组执行，而不是Android权限验证机制。特别是，当应用程序安装了internet、WRITE_EXTERNAL_STORAGE或蓝牙权限时，它被分配给一个Linux组，这个组可以访问相关的套接字和文件。因此，Linux内核强制这些权限的访问控制策略。因此，API库(与应用程序具有相同的权限)可以直接对这些套接字和文件进行操作，而不需要在系统进程中调用API实现。
本机代码。应用程序可以在转换为Java代码的过程中包含本机代码，但是本机代码仍然受制于权限系统。试图打开套接字或文件是由Linux权限决定的。本机代码不能与系统API直接通信。相反，应用程序必须创建Java包装器方法来代表本地代码调用API。在执行API调用时，Android权限将像往常一样强制执行。
2.2.2内容提供商
系统内容提供程序作为独立的应用程序安装，独立于系统进程和API库。它们受到静态和动态权限检查的保护，使用与应用程序相同的机制来保护它们自己的内容提供者。
静态声明将每个任务的读和写分配给给定的内容提供程序。默认情况下,这些权限应用于托管提供程序存储的所有资源。通过将权限与路径(例如，内容://a/b)关联，还可以在更细的粒度上应用限制。例如，同时存储公共和私有notes的内容提供程序可能希望为整个内容提供程序设置默认权限要求，但随后允许不受限制地访问公共notes。类似地，可以为cer- tain路径设置额外的权限要求，只有当调用应用程序具有提供者的默认权限和特定于路径的权限时，才可以访问这些路径下的数据。
内容提供程序还可以强制执行权限程序:处理查询的内容提供程序代码可以显式地调用系统的权限验证机制来要求特定的权限。这使devel- oper能够更好地控制权限执行机制的粒度，允许她有选择地要求查询值或数据库数据的权限。
2.2.3意图
Android的Intent系统被广泛用于应用程序间和应用程序内的通信。为了防止应用程序模仿系统意图，Android限制了谁可以发送某些意图。所有意图都通过Ac- tivityManagerService(一个系统服务)发送，它强制执行这个限制。有两种技术用于限制系统意图的发送。有些意图只能通过具有适当权限的应用程序发送。其他系统意图只能由UID与系统id匹配的进程发送。后一类的意图不能由appli- cations发送，无论它们拥有什么权限，因为这些意图必须来自系统进程。
应用程序可能还需要权限来接收某些系统意图。操作系统使用标准的Android mecha- nism来限制它的意图接收者。应用程序(在本例中是操作系统)可以通过将权限要求附加到意图[13]来限制谁可以接收意图。
3.允许测试方法
Android的访问控制策略没有很好的文档，但是该策略对于确定应用程序是否被过度特权是必要的。为了解决这个缺点，我们根据经验确定了- droid执行的访问控制策略。我们使用测试来构建一个权限映射，它标识Android API中每个方法所需的权限。特别是，我们修改了Android 2.2权限验证机制，用于在权限检查发生时记录它们。然后我们为API调用、内容提供者和意图生成单元测试用例。执行这些测试允许我们观察与系统api交互所需的权限。核心挑战是构建单元测试，以获得所有平台资源的调用覆盖率。
3.1 API
如2.2.1所述，Android API为应用程序提供了一个库，其中包含公共的、私有的和隐藏的类和方法。私有类集包括用于系统服务的RPC存根。所有这些类和方法都可以被使用Java反射的应用程序访问，所以我们必须测试它们来识别权限检查。我们将测试分为三个阶段:反馈导向测试;可定制的测试用例生成;和
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
