英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料
安卓权限使用揭秘
作者：Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, David Wagner
加州大学伯克利分校
邮箱：{ apf, emc, sch, dawnsong, daw }@ cs.berkeley.edu
摘要
Android系统为第三方应用程序提供了广泛的API，其中包括了一些允许访问手机硬件，系统设置和用户数据的API。而API中隐私和安全相关部分的访问授权是通过一个在安装时对应用程序权限进行授权的系统进行控制的。我们研究了大量Android应用程序以确定Android开发人员是否遵循其权限使用要求中所描述的最低权限准则。我们构建了一个名为Stowaway的工具，它能够在已经编译的Android应用程序中检测程序权限滥用的情况。Stowaway能够确定应用程序所调用的API的集合，然后将这些API调用的集合映射到应用程序权限的集合中。我们在Android API上使用自动化测试工具，以此构建检测权限滥用情况所必需的映射关系。我们将Stowaway应用于940个应用程序中，并且发现大约三分之一的应用程序有滥用权限的情况。我们调查权限滥用的原因，并找到了一些能够证明开发人员尝试遵循最低权限，但有时会因为API文档不足而失败的证据。
类别和主题描述
D.2.5 [软件工程]：测试和调试;
D.4.6 [操作系统]：安全和保护
一般术语
安全
关键词
Android，权限，最小权限
介绍
Android系统的不对程序进行限制的应用程序市场及其开源环境使它成为流行的第三方应用程序平台。截止至2011年，Android 的应用市场包含的应用程序比苹果的 App Store更多[10]。Android通过大量的API为第三方开发提供支持，这些API为应用程序提供对移动设备硬件（例如相机）、Wi-Fi、蜂窝网络、用户数据和电话设置的访问。
Android各种丰富的与隐私、安全部分相关的API使用许可是由一个安装时运行的应用程序权限系统控制。每个应用程序必须预先声明它需要使用的权限，并且在安装过程中通知用户程序将收到哪些权限，如果用户不想向应用程序授予权限，那么他或她可以取消这个安装过程。
安装时进行权限授权能为用户提供对其隐私的控制，并减少应用程序中的错误和漏洞所带来的影响。但是，如果开发人员经常请求比他们所需权限多得多的权限，那么安装时权限授权系统将变得没有效果。权限滥用的应用程序会向用户发出不必要的权限警告，并增加错误或漏洞带来的影响。我们研究Android应用程序以确定Android开发人员是否遵循最小权限原则或在他们的应用程序中滥用权限。
我们提供了一个名为Stowaway的工具，它可以检测已编译的Android应用程序中的权限。Stowaway工具由两部分组成：一个静态分析工具，它用于确定应用程序调用的API；以及一个权限映射，用于标识调用每个API所需的权限。Android的文档没有为此类分析提供足够的权限信息，因此我们根据经验确定了Android 2.2系统的访问控制策略。通过使用自动化测试技术，我们实现了85％的Android API覆盖率。我们的权限映射关系提供了对Android权限系统的深入了解，使我们能够识别权限滥用情况。
我们将Stowaway应用于Android应用市场中的940个Android应用程序，并发现大约三分之一的应用程序是滥用权限的。滥用权限的应用程序一般只额外请求了几个权限：超过一半的权限只包含一个额外的权限，而且只有6％的应用程序申请了四个以上并不需要的权限。我们调查了权限滥用的原因，并发现许多开发人员的错误源于对权限系统的混乱认识。我们的结果表明：开发人员正在尝试遵循最低权限原则，这支持了与Android类似的在安装时进行权限授权的系统在有效性方面拥有潜力（的论点）。
Android提供了开发人员文档，但其有关权限使用的信息十分有限，缺少可靠的权限信息可能会导致开发人员犯错。这些文档仅仅列出了78种方法所需的权限要求，而我们的测试却揭示了1259种方法的权限要求（比文档高了16倍）。此外，我们还在Android权限文档中发现了6个错误。这种不精确使得开发人员需要通过猜测或留言板来获得补充的参考资料。而开发人员的混乱可能会导致在应用程序滥用权限，因为开发人员经常尝试添加不必要的权限来让他们的应用程序正常工作。
贡献：我们提供了如下贡献：
- 我们开发了Stowaway，一种用于检测Android应用程序中的特权的工具。我们使用Stowaway评估了来自Android应用市场的940个应用程序，并发现大约三分之一的程序存在滥用权限的情况。
- 我们识别并量化了导致开发人员滥用权限的错误模式。
- 通过使用自动化测试技术，我们确定了Android的访问控制策略。我们的结果比文档提高了十五倍。
其他已有工具[11,12]和将来的程序分析可以利用我们的权限映射关系来研究Android应用程序中的权限使用情况。Stowaway和权限映射数据可以在android-permissions.org中找到。
组织结构：第2节提供了一个关于Android及其权限系统的概述，第3节讨论了我们的API测试方法，第4节描述了我们对Android API的分析。第5节描述了我们用于检测特权的静态分析工具，第6节讨论了我们的应用程序特权分析。
安卓权限系统
Android拥有范围广泛的API和权限系统。我们首先提供了一个有关Android应用程序平台和权限的高层次概述。然后，我们将提供一个有关Android权限如何执行的详细介绍。
2.1Android的背景知识
Android智能手机用户可以通过Android 应用市场[3]或亚马逊应用商城[1]安装第三方应用程序。这些第三方应用程序的质量和可信度差异很大，因此Android会将所有应用程序视为潜在的错误或恶意应用程序。每个应用程序都在具有低权限用户ID的进程中运行，并且应用程序在默认情况下只能访问自己的文件。这些应用程序是用Java编写的（可能附带已经被编译过的机器码），而且每个应用程序都只能在自己的虚拟机中运行。
Android使用在安装时赋予权限授权的方式来控制程序对系统资源的访问。 Android 2.2定义了134个权限，分为三个威胁级别：
-
- 普通权限可以对调用时会访问那些可能会烦扰但不会损害用户的功能的API进行防护。例如，SET_WALLPAPER权限控制应用程序能否更改用户背景墙纸。
- 危险权限控制那些可能对造成损害的API调用，像是和消费或收集私人信息相关的API的调用。 例如，发送短信或阅读联系人列表需要具有危险权限。
- 签名/系统权限控制那些对最危险权限进行的访问，例如控制备份过程或删除应用程序包的功能。这些权限很难获得：签名权限仅授予使用设备制造商证书签名的应用程序，而签名或系统权限仅授予放在特殊系统文件夹中签名或安装的应用程序。这些限制实质上保证了只有预安装的应用程序才能获得签名/系统权限，并且将其他应用程序对签名/系统权限的申请忽略。
应用程序也可以出于自我保护的目的定义属于它们自己的权限，但我们专注于分析那些保护系统资源的Android定义的权限。我们在分析的任何阶段都不会考虑开发人员自己定义的权限。同样，我们不会考虑谷歌自己定义的包含在谷歌应用程序中（例如谷歌阅读器）但不是操作系统的那部分权限。
在与系统API、数据库和消息传递系统进行交互时可能需要权限。那些公共API [2]描述了8648个方法，其中一些方法受权限保护。用户数据存储在内容提供器中，而操作某些系统的内容提供器需要请求权限。例如，应用程序必须具有READ_CONTACTS权限才能在联系人内容提供器（Contacts Content Provider）上执行READ查询事务。应用程序还可能需要从操作系统接收Intents的权限。Intents通知应用程序事件，例如网络连接的更改，而且系统发送的某些Intent只会传递给具有相应权限的应用程序。此外，应用程序需要有相关权限才能发送与操作系统发出内容相似的Intents。
2.2权限执行机制
我们描述了系统API，内容提供器和Intent是如何被实现以及保护的。 据我们所知，我们是第一个描述Android权限执行机制细节的人。
2.2.1 API
API结构：Android API的框架由两部分组成：储存在每个应用程序的虚拟机中的库和在系统进程中运行的API的实现。这些API库的运行权限与其附带的应用程序相同，而系统进程中的API实现则没有任何限制。该库提供了与API实现进行交互的语法糖。而那些读取或更改全局电话状态的API调用则被库函数代理到系统的进程中进行实现。
API调用分为三个步骤处理（如图1所示）。首先，应用程序调用库中的公共API。 接着，库中的函数调用相同库中的私有接口，这个私有接口是一个RPC存根。第三，RPC存根使用系统进程发起RPC请求，这个请求要求系统执行所需的操作。 例如，如果应用程序调用ClipboardManager.getText（）方法，则调用将被中继到IClipboard $ Stub $ Proxy中，后者代理对系统进程中键盘服务（ClipboardService）的调用。
图1 安卓平台架构：权限检查在系统进程中进行机制
应用程序可以使用Java的反射机制[19]来访问所有API库的隐藏和私有类，方法和字段。一些私有接口没有任何相应的公共API，但是，应用程序仍然可以使用反射机制来调用它们。这些非公共的库方法旨在提供给Google应用程序或框架本身使用，并建议开发人员不要使用它们。因为它们可能会随着发行版本发生变化或消失[17]。但是，依然有一些应用程序会使用它们。在系统进程中运行的Java代码位于一个单独的虚拟机中，因此不受反射的影响。
权限：为了强制执行权限，系统的各个部分调用权限验证机制来检查给定的应用程序是否具有指定的权限。权限验证机制是作为被信任的系统进程的一部分实现的，权限验证机制的调用遍布所有的API。在调用API时，没有用于检查权限的集中化策略。相反，（权限验证的）判定发生在权限验证程序被正确调用的位置。
权限检查放在系统进程的API实现中。 必要时，API实现会调用权限验证机制来检查调用应用程序是否具有必要的权限。在某些情况下，API库也可以冗余地检查这些权限，但是却不能依赖这些检查，因为应用程序可以绕过它们，直接通过RPC存根与系统进程进行通信。因此，不应该在API库中进行权限检查，与之相反，应该在系统进程中的API实现里调用权限验证机制进行相应的检查。
有少数权限必须由UNIX，而不是Android权限验证机制来执行。特别是当应用程序使用INTERNET，WRITE_EXTERNAL_STORAGE或BLUETOOTH权限安装时，系统会将其分配给可以访问相关套接字和文件的Linux组。因此，Linux内核将会为这些权限执行访问控制策略。API库以与应用程序相同的权限运行，因此可以相应地直接在这些套接字和文件上运行，而无需在系统进程中调用相应API实现。
机器码：除Java代码外，应用程序还可以包含机器码，但机器码仍然适用于权限系统。尝试打开套接字或文件的操作是由Linux权限调解的。机器码无法直接与系统API通信，作为替代，应用程序必须创建Java包装器方法来代表机器码调用API。而在执行API调用时，Android权限将会照常执行。
2.2.2 内容提供器
系统内容提供器作为独立的应用程序进行安装，并与系统进程和API库分开。它们受静态和动态权限检查保护，使用和应用程序相同的机制来保护自己。
静态声明为一个给定的内容提供器分配单独的读取和写入权限。默认情况下，这些权限也适用于内容提供器存储的所有资源。还可以通过将权限与路径相关联（例如，content://a/b），将（对权限的）限制应用在更精细的粒度范围内。例如，一个同时存储了共有和私有信息的内容提供器，可能希望为自己的所有内容设置默认的权限要求，但又允许不受限制地范围其中的共有内容。那么，可以用类似的方式为额外权限设置特定的路径，使得进行调用的应用程序只有在同时具有默认权限以及该路径特定的权限时，才能访问这些路径下的数据。
内容提供器还可以以编程的方式强制执行权限检查：内容提供器中处理查询事务的代码可以显式地调用系统的权限验证机制从而检查特定的权限是否满足要求。这使开发人员可以更好地控制权限执行机制的粒度，并允许他们有选择性地为查询数值或数据库数据要求检查权限。
2.2.3 Intent
Android的Intent系统广泛用于应用程序间和应用程序内部通信。为了防止应用程序模仿系统Intents，Android限制了哪些组件可以发送哪些特定的Intent。所有Intents都通过ActivityManagerService（一种系统服务）发送，这可以确保上述限制的执行。有两种技术被用于限制系统级Intent的发送。某些Intent只能由具有适当权限的应用程序发送，而其他的系统级Intent只能由UID与系统匹配的进程发送。应用程序无论拥有什么权限，都不能发送
全文共6690字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[502]
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
