1、第15章 基于系统安全机制的防护15.1 系统安全基础系统安全基础操作系统的安全访问控制模型通常表述为一个主体(subject)可以访问哪些对象(object)。主体是指可以授予或拒绝访问某个对象的人或事物，如用户、程序、系统进程。对象是指被访问的某种系统的资源，如文件、打印机等。目前操作系统安全隔离技术包括自主访问控制(Discretionary Access Control，DAC)和强制访问控制(Mandatory Access Control，MAC)两种类别，后者是安全的操作系统必要的选择。第15章 基于系统安全机制的防护DAC基于主体的身份或者主体所属的组别来限制对象的访问权限，主
2、要技术特征是主体具有的访问权限能够通过继承或者赋予被传递给另外一个主体。这意味着访问权限具有传递链条，因此，当一个程序中发生安全事件时，会危及系统，使得DAC在木马面前特别脆弱。目前，最著名的DAC实现是基于用户ID和组(group)的UnixLinux文件系统的权限系统。第15章 基于系统安全机制的防护举例来说，在Linux文件系统中，用户A拥有文件file1且对file1拥有读写权限，对其他用户则关闭读写权限。用户(恶意攻击者)C编写程序。该程序在执行时生成文件file2且在程序中设置新的访问列表，即用户A对file2的写权限和用户C对file2的读权限。用户C将恶意程序伪装成合法程序发给
3、用户A，当程序被A运行时，程序就具有了A的访问权限。在程序逻辑中拷贝file1到file2，用户C就窃取了file1的内容。如果用户A是系统管理员，攻击者C会获取最大的权限。第15章 基于系统安全机制的防护在MAC的实现中，存在多种对象标记和策略判断规则，不同MAC系统的实现并不一样。在iOS和Android的应用沙箱技术中，均采用某种程度的MAC技术实现。iOS在操作系统内核层面实现MAC，而Android在中间层实现MAC。iOS的应用沙箱是一种强限制的结构，iOS将应用限制的级别定义为“每一个应用都是一个孤岛”。为了软件安全，该设计极大程度地推崇应用隔离，而牺牲了本机内应用间的信息共享。
4、第15章 基于系统安全机制的防护图15-1所示为来自苹果公司官方文档的iOS应用沙箱。图15-1 iOS中的沙箱第15章 基于系统安全机制的防护应用“孤岛”是如何形成的呢？iOS应用沙箱提供细粒度的应用权限访问控制，其应用沙箱的主要访问限制可以总结如下：(1)应用只看到沙箱容器目录，表述为，规定其不可见系统的其他目录和整个文件系统，沙箱中的关键子目录有/AppName.app、/Documents/、/Documentshnbox、/Library/等，每个子目录的使用方法有严格规定。第15章 基于系统安全机制的防护(2)/Documents/Inbox只有读和删除的权限，没有写的权限。(3)
5、应用可以对用户的照片、视频内容及iTunes目录进行只读访问。(4)应用可以对用户的联系人数据(SQLite本地文件数据库)进行读/写访问。(5)应用可以启动网络连接以发送和接收数据。第15章 基于系统安全机制的防护(6)应用仅通过系统API执行有限制的后台服务。(7)应用不可以读取系统的日志目录。(8)不在权限列表中描述的操作均不能通过授权等。iOS的应用沙箱不是基于Unix用户ID的权限控制DAC方案，而是操作系统内核层次的MAC的实现，操作系统集成了TrustedBSD MAC Framework项目，以实现应用沙箱。iOS的应用沙箱的执行结果，可参照iOS操作系统的同源操作系统MAC
6、OS X的sandbox-exec命令来观察。第15章 基于系统安全机制的防护iOS/MAC OS X对不同的应用类型，定义不同的沙箱。沙箱的访问权限定义配置文件可以使用SBPL(SandBox Policy Language)，以正则表达式的语法来描述。在应用启动的同时沙箱启动，沙箱的配置被传递到操作系统内核执行。iOS应用沙箱的强大之处不仅在于单纯的技术实现，还在于苹果公司严格的审核测试。应用在发布到苹果的应用商店之前，需经过苹果公司严格的审核测试，如果应用不遵循沙箱的设计规格则不能正常运作，或将在审核环节被废弃。即使应用在上市之后被发现有恶意的行为仍会被作下架处理。第15章 基于系统安全
7、机制的防护与iOS操作系统对应，Android操作系统的沙箱技术是基于Linux的原生进程与用户账号组合来进行限制的技术。Android是多用户的Linux操作系统，每个应用使用不同的用户ID运行进程，并对应用的数据文件进行Linux操作层次的文件访问保护，赋予且仅赋予程序用户的ID以访问其权限，使用其他用户ID运行的程序无法越权访问程序所保护的数据。Android应用签名不要求权威的中心进行认证，其验证签名仅是为了区分应用的提供商身份，相同应用提供商签名的多个应用可以在同一个进程空间运行，彼此间能够更紧密耦合地共享数据访问。第15章 基于系统安全机制的防护操作系统层面基于Linux用户ID的
8、权限控制是一种DAC的权限控制，DAC的缺点如上文所述，使系统在面对木马恶意程序时表现脆弱。为保持Linux内核的相对独立性，Android在Linux之上的中间层添加了MAC式的权限控制permission机制，根据应用安装时用户的授权权限定义进行敏感数据和操作许可的判断。下面阐述的是Android的permission机制。第15章 基于系统安全机制的防护Android对系统中的各种资源访问能力定义了详细的权限要求列表。例如，读取联系人的权限为read_contacts，发送短信的权限为send_sms，访问摄像头的权限为camera等。在用户下载安装应用的时候，应用列出所需的软件授权权限
9、列表，用户必须在同意给予授权后才能继续安装应用。应用安装成功后，针对限制应用的沙箱生成，该沙箱限制应用只能访问用户授权的能力访问范围。在某种Android手机上，通过“设置”“其他管理应用”“所检查的应用程序”“查看权限详情”等一系列操作，最终的权限列表如图15-2所示。第15章 基于系统安全机制的防护图15-2 某应用软件所具有的权限第15章 基于系统安全机制的防护15.2 Android权限机制的改进权限机制的改进15.2.1 Android安全机制基础安全机制基础Android作为智能手机广泛采用的移动操作系统，由于智能手机中存放着大量高度隐私敏感的个人数据，因此对Android生态系统
10、以及用户个人数据的安全性提出了更高的安全要求。为保证用户数据的安全以及隐私，Android采用基于权限的安全模型来限制对敏感数据(如位置、通话记录、联系人数据等)的访问。第15章 基于系统安全机制的防护然而，Android权限机制对用户数据安全性的保护不能达到预期的安全防御效果，所以研究者对权限机制进行了改进，包括改进安装时期的权限以帮助用户对权限的理解、权限机制设计上的漏洞分析与防御方法、利用权限对程序安全性进行分析研究这三部分。权限的赋予可分为两类：一类是高层组件，例如应用和系统服务，采用包管理器进行管理和查询；一类是底层组件，利用传统的Linux DAC机制进行管理，不直接访问包管理器。
11、第15章 基于系统安全机制的防护1.底层权限管理底层权限管理Android进程主要是通过UID、GID以及一组补充的GID来实现的。Android沙箱以UID为基础实现(可参看上一小节中Android中的沙箱应用)，每个进程拥有自己独特的UID(先不考虑共享UID)。进程UID和GID由包管理器映射到应用程序的UID。补充GID则为额外的权限。内置权限到组的映射是静态的。第15章 基于系统安全机制的防护从代码可知，“android.permission.BLUETOOTH_ADMIN”映射到GID的3001。包管理器在读取platfrom.xml时，同时维护一个权限到GID的列表。在对安装中的
12、包进行授权时，包管理器会检查每个权限是否有对应的GID。如果有，则加入到补充GID列表中。此时仅确定了进程需要赋予哪些额外的GID。那Android是如何赋权的呢？当Android启动新进程时，为减少程序所需内存并加快启动时间，Android会直接fork()Zygote进程，并执行Android特有的函数进行分化而不执行固有的exec函数。第15章 基于系统安全机制的防护2.高层权限管理高层权限管理在了解高层权限管理之前，先介绍包管理器所维护的安装程序包核心数据库，该数据库以xml文件的形式放入/data/system/packages.xml中。码包括安装路径、版本号、签名证书和每个包的权
13、限。上层的管理通过包管理器及该数据库进行交互。由于组件无法在运行时修改权限，因此权限执行检查都是静态的。执行分为两类，分别是静态和动态。静态执行和动态执行流程大致相同：首先，Binder.getCallingUid()和Binder.getCallingPid()获取调用者的UID和PID，然后利用UID映射包名获得相关权限。如果权限集合中含有所需权限即启动，否则抛出SecurityException异常。第15章 基于系统安全机制的防护Android权限机制的实现包括安装时期以及运行时期两部分。用户在安装时期完成对权限的授权工作，在程序运行期间Android系统通过引用监视器判断应用程序是否
14、具备使用特定功能的权限。关于Android权限机制改进的相关研究工作是从安装时期及运行时期两个角度展开的。详细描述Android SD卡上文件的存储保护。因为智能终端硬件资源的有限性及Android系统本身所具有的特点，内存空间远远不能满足实际需求，所以需要依靠SD卡来辅助解决，因此存储在SD卡上的数据安全也成为Android应用安全中必须考虑的重要一环。下面介绍Android SD卡访问机制，以及开发者如何保障开发的App存储在SD卡上数据的安全。第15章 基于系统安全机制的防护Android的访问SD卡的机制(Android系统在启动过程中的Vold进程、mount SD卡的流程、系统运行
15、过程中对SD卡操作的流程)如图15-3所示。下面从Android系统启动过程加载SD卡、系统运行过程中加载SD卡、系统应用程序访问SD卡三个方面简要分析SD卡的访问机制。第15章 基于系统安全机制的防护图15-3 访问SD卡机制第15章 基于系统安全机制的防护1)系统启动加载SD卡Android系统启动后，内核启动的第一个用户级进程为init进程。init进程读取system/core/rootdir/init.rc文件，获得需要启动的服务列表，从列表中依次启动服务子进程。其中，init会启动Vold服务，init.rc文件中启动Vold的代码如以下的代码片段1所示，开机过程中SD卡的moun
16、t过程在Vold服务中实现。Linux系统中的Udev进程是用户空间的进程，主要功能是提供一种基于用户空间的动态设备节点管理和命名的解决方案。而在Android系统中，用Vold进程取代Udev进程。Android系统中Vold(Volume Dameon)进程的主要功能是用来挂载、管理USB存储设备和SD卡设备。第15章 基于系统安全机制的防护第15章 基于系统安全机制的防护如图15-3所示，Vold通过process_config()函数读取并解析SD卡的配置文件system/core/rootdir/etc/vold.fstab。dev_mount代表挂载格式，sdcard代表挂载标签，
17、/mnt/sdcard代表挂载点，auto代表自动挂载。解析完该文件之后，process_config()函数通过以下的代码片段2来实例化DirectVolume类实现SD卡的挂载。至此完成了启动系统时加载SD卡的过程。第15章 基于系统安全机制的防护2)系统在运行过程中加载SD卡在Android手机通过USB接口连接PC对SD卡中的文件资源进行拷贝时，会出现Android系统在开机状态下对SD卡的mount和unmont操作，此过程属于外设的热插拔。SD卡的热插拔也由Vold服务提供支持。Vold服务基于sysfs，sysfs为内核与用户层的通信提供全新的方式，并将该方式加以规范。如图15-
18、3所示，内核检测到有新的设备接入到系统，即为之加载相应的驱动程序。第15章 基于系统安全机制的防护sysfs机制将新设备的状态通过uevent通知给Vold进程，Vold的NetlinkManager监听到Kernel层上报的uevent事件并对其进行解析和处理，通过CommandListener向Framework层的NativeDaemonConnector类发送相应通知，Framework层再对收到的通知进行解析、判断和传递，最后将新设备的状态广播通知给应用层，应用层收到广播后进行更新UI等操作。第15章 基于系统安全机制的防护3)应用程序访问过程中加载SD卡文件系统由于SD卡使用的是F
19、AT32(File Allocation Table)文件系统，所以单独的SD卡没有访问权限控制。但是Android系统的应用程序要访问SD卡必须获得Android系统的授权，应用开发者需要在应用程序的AndroidManifest.xml文件中加入如以下代码片段3所示的权限代码。第15章 基于系统安全机制的防护Android系统对于SD卡的整个文件系统只有访问与不能访问的权限控制，而某个应用程序产生的文件并没有类似内部SQLite数据的sandbox机制，即只要申请到访问SD卡的权限即可任意读取、篡改SD卡里的大部分文件。SD卡的存储机制存在巨大的安全隐患，如图15-4所示。App A、Ap
20、p B、App C等应用程序在运行过程中产生自己的文件File A、File B、File C，但是恶意程序Malwares只要申请了访问SD卡的权限就可以访问并篡改该文件，容易造成用户的照片、记事本等隐私数据的泄露。由此可见，Android系统SD卡中的文件系统安全机制极为薄弱，研究对SD卡中隐私文件的保护有着重要的实用价值。第15章 基于系统安全机制的防护图15-4 SD卡存储机制的安全隐患第15章 基于系统安全机制的防护4)Android SD卡访问机制缺陷由以上分析可知，Android系统SD卡文件访问控制权限粒度较大，应用程序存入SD卡的外部文件容易暴露。而开发者不会对自己的外部文件
21、进行保护，即使对该文件进行保护处理也必须由开发者利用自己的方式来实现保护。该机制无疑增加了开发者保障文件安全的成本，也让SD卡的文件保护陷入了尴尬局面 没有系统级文件保护机制的支持。应用程序的文件保护或没有，或各应用程序的保护方式杂乱无章、效率低下，系统难以对其进行高效的统一管理和维护。第15章 基于系统安全机制的防护15.2.2 安装时期权限改进安装时期权限改进用户如果想安装并使用该应用程序的功能，就必须对应用程序所申请的全部权限进行授权，如果拒绝授权，则应用程序包安装器将拒绝安装该应用。因此，Nauman等人提出了一个细粒度的Android使用控制模型，允许用户准确地指定设备中的哪些资源允
22、许被访问，而哪些该应用程序所申请的权限不允许被授权。这些决策还能够基于运行时期的限制，比如在某些特定的时间、设备所在的地点或者一天中短信发送的最大数量等。通过修改应用程序包安装器实现了他们的方案，并可为用户提供容易使用的策略定制客户端。第15章 基于系统安全机制的防护Android权限机制是在安装时期确定的，不能根据运行时环境的不同动态修改应用程序访问资源的能力。比如用户在某个秘密的场合下，所有应用程序的连接互联网、录音等权限都应该是不能授予的。对此，Conti等人提出了CREPE，这是一个根据上下文(如位置、时间、温度、噪声、光强等因素)来实施细粒度访问策略的访问控制系统。第15章 基于系统
23、安全机制的防护由于Android已有的权限机制缺少对已安装的应用程序的保护，因此该权限机制设计上的疏忽容易使恶意程序利用已安装应用程序的权限完成权限扩大(权限提升攻击)。Saint为开发者提供了更为细致的安全策略限制，使已安装的应用程序免遭其他恶意程序的利用。Saint使得应用程序开发者可以从应用程序的角度来具体声明允许进出交互的应用程序。具体来讲该机制定义了安装时和运行时的策略。第15章 基于系统安全机制的防护(1)在应用程序安装时的权限分配。允许声明权限P的应用程序根据应用签名以及配置等条件，依据开发者自定义的安全策略对本应用的对外接口实施保护。(2)在运行时的策略中，该机制在Androi
24、d中间件中额外设计调用管理器，运行时策略根据应用程序签名、配置以及运行上下文等条件提供调用者和被调用者的策略，允许应用程序限制哪些应用程序可以访问它的接口以及它可以与哪些应用程序接口交互。第15章 基于系统安全机制的防护15.2.3 运行时期权限改进运行时期权限改进Android在安装时期完成对不同应用程序的权限授权，在运行期间对应用程序发起的敏感API访问进行访问控制。Android权限框架是由Android中间件提供的，包含一个对进程间通信(Android系统中的组件间通信)实施强制访问控制的引用监控器。安全敏感的API受在安装时期赋予的权限的保护，然而Android权限机制存在权限提升攻
25、击的缺陷。第15章 基于系统安全机制的防护权限提升攻击是指一个拥有少量权限的应用程序(没有特权的调用者)允许访问拥有更多权限的应用程序的组件(有特权的被调用者)，攻击演示如图15-5所示。由于未被赋予相应的权限P1，所以应用程序A没有权限去访问位置信息，但是应用程序A可以通过其他方式访问到位置信息，如通过应用程序B的组件(2跳)。由于应用程序A无需权限即可访问应用程序B，并且应用程序B具有访问位置资源的权限P1，所以应用程序A可以通过与应用程序B的交互来达到访问位置信息的目的。第15章 基于系统安全机制的防护图15-5 权限提升攻击演示第15章 基于系统安全机制的防护QUIRE是Android
26、安全的扩展，提供轻量级的来源系统以防止混淆代理人攻击，是由Dietz等人基于Java堆栈检查的原理设计的。为了确定安全关键性操作的源头，QUIRE跟踪并记录了ICC调用链，在源头应用程序没有包括相应权限的情况下拒绝请求。该方法为应用程序开发者提供了访问控制原型。然而，QUIRE不能解决由共谋的恶意应用程序带来的权限提升攻击。IPC inspection则缩小了被调用应用程序的权限，若某应用程序接收到来自其他应用程序的调用(如绑定服务、接收广播的消息、打开活动等)，则将被调用者的权限减少为调用者与被调用者权限的交集，但是它也无法防御共谋带来的权限提升。第15章 基于系统安全机制的防护之前的方案(
27、QUIRE、IPC inspection)仅解决混淆代理人攻击带来的问题，Bugeiel等人针对使用所有通信信道带来的权限提升攻击问题，提出了XManDroid以及TrustDroid。XManDroid是一个依靠系统策略检测和阻止Android应用程序权限代理攻击的方案，能够实现对通过Android系统服务或内容提供者建立秘密通道的有效检测。在运行时，XManDroid监控应用程序之间发起交互请求，并将通信双方应用程序包含的权限根据策略数据库中定义的策略进行判定，以确定是否可以发起通信。第15章 基于系统安全机制的防护XManDroid使用图来表示系统，图的节点表示应用程序，无向边表示被授权
28、的组件间通信，形式化描述应用程序间通信的过程。TrustDroid在XManDroid的基础上增加了内核级别的模块，以防止通过其他信道完成应用程序间通信，当应用程序执行文件或socket操作时，该操作将被增加的Linux内核下的强制访问控制模块进行处理。TrustDroid通过部署TOMOYO Linux实现内核级别的强制访问控制。第15章 基于系统安全机制的防护15.3 通过通过iOS安全机制加强防护安全机制加强防护15.3.1 iOS安全基础安全基础iOS安全机制除了采用沙箱技术外，还采用安全启动链、代码签名、地址空间布局随机化及数据保护等技术。下面分别对这四种技术进行介绍。第15章 基于
29、系统安全机制的防护1.安全启动链安全启动链iOS系统启动过程的每一个步骤都包含由Apple签名加密的组件，以此保证该步骤正确、完整，且仅当验证信任链后步骤才得以进行。加密的部件包括bootloader、kernel、kernel extensions和baseband firmware。该安全启动链在确保系统最底层的软件不会被非法篡改的同时确保了iOS启动只会在经过验证的iOS设备上运行。如果该启动过程中的任何一个步骤验证出现问题，启动过程就会终止并强制系统进入恢复模式(Recovery Mode)，当Boot ROM都无法成功启动LLB时，设备将直接进入DFU(Device Firmware
30、 Upgrade)工厂模式。第15章 基于系统安全机制的防护2.代码签名代码签名为确保应用程序不被非法篡改，iOS要求所有执行代码必须经过由Apple颁发的证书签名。代码签名机制受控于强制性访问控制框架(Mandatory Access Control Framework，MACF)，该系统框架由FreeBSD的Trusted BSD MAC Framework继承而来。MACF允许有追加的访问控制策略，并且新的策略在框架启动时被载入。第15章 基于系统安全机制的防护3.地址空间布局随机化地址空间布局随机化地址空间布局随机化(ASLR)是从iOS4.3开始引入的安全机制，作用是随机化每次程序在
31、内存中加载的地址空间，将重要的数据(比如操作系统内核)配置到恶意代码难以猜到的内存位置，令攻击者难以攻击。4.数据保护数据保护Apple在iOS中引入数据保护(Data Protection)技术来保护存储在设备Flash内存上的用户数据。第15章 基于系统安全机制的防护不同的保护类是通过一个层次结构的密钥体系实现的。在密钥体系中，每一个密钥都是通过其他的密钥和数据继承而来的。部分跟数据加密有关的体系如图15-6所示。在该结构的根部是UID密钥与用户密码，在上面章节里已经提到UID是设备唯一的、存在于板载加密运算器芯片里的数据，不可被直接读取，但可以用它来进行加密解密数据。每当设备被解锁后，设
32、备密码会经过改进的PBKDF2算法进行多次加密运算以生成设备密码密钥(Passcode Key)，设备密码密钥会一直存在于内存中直到用户再次锁定设备才会被销毁。第15章 基于系统安全机制的防护UID密钥还被用来加密静态字符串以生成设备密钥(Device Key)，设备密钥用来加密各种代表文件相关的保护类的类密钥(Class Key)。有一些类密钥也会同时经过设备密码密钥加密，这样能保证该类密钥只有在设备被解锁时才有效。数据保护应用程序接口(Data Protection API)是用来让应用程序声明文件或Keychain项目在何时被加密，并通过向现有的应用程序接口里添加新定义的保护类标记使加密
33、后的文件或者Keychain项目随时能重新被解密。第15章 基于系统安全机制的防护图15-6 同数据加密有关的体系第15章 基于系统安全机制的防护要对某个文件进行保护，应用程序需要使用NSFileManager类对NSFileProtectKey设置一个值，所有支持的值及其代表的含义如表15-1所示。第15章 基于系统安全机制的防护15.3.2 静态的权限评估静态的权限评估权限分析包括应用程序中传统的Unix文件系统权限分析和entitlements分析。由于IPA安装的程序处于沙箱体系中，因此只有mobile权限。而DEB程序解包后可用shell命令检查文件系统权限，分析安装脚本中安装时是否
34、对程序或者目录权限进行了更改，另外从程序的类型可直接得出程序可能具有的权限。iOS的应用程序取得root权限有两个方式，一个是通过设置Unix标记位，另一个是权限继承。第15章 基于系统安全机制的防护使用ldid或者codesign命令能够导出应用程序entitlements的XML文件并分析其中的权限键值对，与具体的权限功能一一对应后导出详细权限表，如应用程序是否具有发送短信的权限，应用程序是否能安装IPA程序等。权限分析后将得到应用程序的权限列表。第15章 基于系统安全机制的防护15.3.3 动态的动态的API调用分析调用分析通过对应用程序执行文件进行反编译处理，可从中解析得到应用程序可能
35、调用的API，但是单从静态分析并不能准确得到在应用程序运行过程中该API被调用的顺序以及场景。通过配置MobileSubstrate的动态库，可以hook所有感兴趣的API并得到在程序真实运行状态下此类API的调用记录序列，记录包括API的名称、传入的参数和调用时间等信息。通过记录可生成API调用时序图以及控制流程图，从而进一步还原应用程序的真实行为意图。第15章 基于系统安全机制的防护下面使用CaptainHook框架对应用程序关键的API进行hook并记录下该调用的详细信息。具体实现如下：(1)声明要hook的类(2)在CHOptimizedMethod()函数中配置具体要hook的函数。
36、对于类方法使用CHOptimizedClassMethod()函数。对CHOptimizedMethod()定义如下：argn是预hook函数的参数个数；obj*是指向hook到的函数所在具体对象的指针；ret_type是函数返回值类型；ClassToHook是函数所在类；fun_name1和fun_name2等是各个函数的名称；函数名称对应的参数和参数类型分别是arg和arg_type。第15章 基于系统安全机制的防护(3)配置MobileLoader的过滤器并将hook动态库加载到指定程序进程中，MobileLoader的过滤器位于/Library/MobileSubstrate/Dyna
37、micLibraries/目录下与hook动态库dylib文件同名的plist文件中。其中过滤器的配置依赖于应用程序的bundleid。对于一些不具有bundleid的程序来说，可通过应用程序执行文件名称来配置。上述过滤器等配置完成后，当应用程序AppToTest试图发送短信时，“-(BOOL)sendSMSWithText:serviceCenter:toAddress:”函数会被调用并被拦截，与此同时调用发生的时间以及描述信息则会被记录到数据库中，最后生成评估报告供研究者分析。第15章 基于系统安全机制的防护15.4 基于权限的应用程序安全性分析基于权限的应用程序安全性分析15.4.1 基
38、于权限的基于权限的Android恶意程序检测恶意程序检测Android权限机制相对于传统权限机制所具有的优点。Android权限机制本身设计的一个优点在于警示用户潜在的安全威胁，即权限潜在反映应用程序的安全性。比如应用程序若申请并被授权接收短信的权限，那么该程序就具备在运行期间访问用户短信数据的能力，或者说该程序会在运行期间访问用户的短信数据，这可能会带来用户短信数据泄露。第15章 基于系统安全机制的防护Kirin根据权限组合是否存在安全威胁设计并实现了基于权限的恶意程序分析框架，该框架由Enck等人最先提出来。他们发现Android在安装应用程序时权限通知了用户应用程序能够访问哪些资源，这可
39、用于检测要求危险权限组合的程序。(具体来说，如要求电话状态、录音和互联网连接的权限组合被认为是危险的，因为申请这种权限组合的应用程序存在成为监听用户通话情况的间谍软件的可能性。)类似地，同时申请访问位置资源、网络以及开机自启动权限的应用程序被认为是跟踪用户位置的恶意应用程序。第15章 基于系统安全机制的防护Sanz等人以权限、字符串、程序评分以及程序大小等应用程序信息作为特征，使用机器学习的方法对应用程序按照其风险进行了自动分类。Zhang等人从权限使用的视角设计了一个恶意程序的动态分析平台VetDroid，该平台能够有效构建出权限使用行为流程。Kirin仅通过权限标记的组合来判断程序是否具有
40、安全威胁，而VetDroid则通过动态分析跟踪程序指令来判断具有安全威胁API的组合的使用情况，并集中分析了应用程序如何通过使用权限的方式来访问系统资源以及在这些权限敏感的资源之后如何被应用程序利用。第15章 基于系统安全机制的防护安全分析者能够通过权限使用行为流程检查应用程序内部的敏感行为。Frank等人对Android以及Facebook应用程序中的权限请求模式进行了统计分析，并且建立模型分析了权限请求模式与应用程序评分之间的关系。除此之外，一些研究者通过分析应用程序不需要申请的权限来判断应用程序是否存在安全威胁。如果应用程序额外申请了一部分权限，可能是因为开发者的疏忽，或是利用不需要的权
41、限实现恶意行为。第15章 基于系统安全机制的防护有研究者设计了基于权限可信性的异常程序分析框架。该框架认为应用程序商店中的程序描述文本反映了程序预期的功能，而程序申请的权限则反映了程序的真实行为。对于良性程序，预期的功能和权限是一一对应的，如果某个申请使用的权限不能通过描述文本体现出来，那么该权限被认为是不可信的。具体来讲，研究者通过应用程序商店中的程序描述文本以及所申请权限的对应关系设计出了异常程序检测系统，并为应用程序描述文本和权限之间建立分析模型，从而实现了自动化地检测出不可信权限，进而判断程序潜在的安全威胁。与此研究工作类似，Pandita 等人使用词性标注、关键词提取等方式对描述文本
42、与权限之间的关系进行了自动分析。第15章 基于系统安全机制的防护15.4.2 Android应用程序中权限申请缺陷检测应用程序中权限申请缺陷检测本书相关章节中提到为防范权限提升攻击在Android操作系统运行时期进行的相关研究工作，权限提升攻击的另一个主要原因是一些Android应用程序中存在权限泄露问题，恶意软件可能会利用存在权限泄露情况的应用程序完成权限的提升。第15章 基于系统安全机制的防护Grace等人对Android设备中预先安装的应用程序进行了显式权限以及隐式权限泄露两种情况下的分析。对于显式权限泄露，恶意程序会利用已安装程序可被公开访问的接口或服务来完成更多权限的获取；对于隐式权
43、限泄露，恶意程序通过开发出与已有程序具有同样签名密钥的方式完成共谋攻击。如果某Android应用程序存在可被公开访问的组件接口，且不同的组件具有访问某些敏感资源的能力，那么该程序存在权限泄露问题。该方案通过分析从Android应用程序不同的组件的入口点出发能够访问到哪些敏感的系统资源的方式检查组件具有访问哪些资源的能力，从而完成上述目标。第15章 基于系统安全机制的防护Bartel等人进行了类似的工作，他们通过静态分析法抽取出程序中的应用程序框架层入口点，在应用程序框架层入口点进行控制流分析直到代码访问到权限敏感的API，以此分析出应用程序入口点与不同权限使用的关系，并利用从代码入口点是否能够
44、访问到之前抽取出的应用程序框架层入口点来判断是否有权限不需要使用。他们认为额外申请的权限一方面由程序开发者的错误造成，另一方面某些恶意程序实现了代码注入导致无法从代码入口点通过静态分析的方式直接访问这些被注入的代码。第15章 基于系统安全机制的防护15.4.3 iOS文件系统权限文件系统权限iOS继承了Unix系统中传统的文件系统权限机制，把进程的权限按照用户和组来划分，绝大多数iOS程序都以mobile权限运行。此外，iOS针对传统的Unix文件系统权限作出了改进，iPhone曾经在2009年爆出的短信漏洞就是利用了非沙箱环境下的iOS系统进程CommCenter的漏洞，由于CommCent
45、er具有root权限而被黑客利用并获取了系统最高权限。而后iOS系统修复了该漏洞，在权限系统里增加了_wireless用户，此后CommCenter不再以root权限运行而是以_wireless身份运行。第15章 基于系统安全机制的防护15.4.4 iOS应用程序权利字串应用程序权利字串除了传统的Unix文件系统权限机制，iOS引入了一种更为细化的权限作为补充，即权利字串(Entitlements)。当应用程序进程需要访问系统的某项服务时，比如请求发送短信，应用程序首先调用发送短信的API，API通过XPC服务把应用程序的请求发送到负责管理短信发送的系统后台Daemon，系统后台Daemon对
46、请求调用API的进程进行审核，检查进程的权利字串是否包含有允许发送短信的内容，如果没有，则拒绝执行该API函数。第15章 基于系统安全机制的防护小小 结结本章从系统安全的角度介绍了如何防护的问题，围绕移动智能终端的iOS与Android两大系统展开讨论。首先介绍两个系统都使用的安全技术沙箱技术，主要介绍沙箱技术的原理及该技术在两个系统中的应用；其次介绍了Android权限机制改进完善的问题。为让读者对该问题了解得更透彻，先介绍了Android系统的安全现状及安全机制。第15章 基于系统安全机制的防护在介绍安全机制时，除了介绍权限机制，又补充介绍了Android存在重大安全缺陷的SD卡访问机制，接着在此基础上介绍Android安全机制的改进问题，从而最大程度地保障Android系统安全。本章第三部分讲解了iOS系统安全机制的改进问题，概括了当前iOS系统的安全机制采用的技术及方法，并描述了改进加强安全的措施及方案(静态的权限评估、动态的API调用分析)。最后对两个系统上的应用程序的安全问题做了简要分析。
