基于访问控制列表机制的Android权限管控方案
2019-12-23曹震寰蔡小孩顾梦鹤顾小卓李晓伟
曹震寰 蔡小孩 顾梦鹤 顾小卓 李晓伟
摘 要:Android采用基于权限的访问控制方式对系统资源进行保护,其权限管控存在管控力度过粗的问题。同时,部分恶意程序会在用户不知情的情况下,在隐私场景下偷偷地对资源进行访问,给用户隐私和系统资源带来一定的威胁。在原有权限管控的基础上引入了访问控制列表(ACL)机制,设计并实现了一个基于ACL机制的Android细粒度权限管控系统。所提系统能根据用户的策略动态地设置应用程序的访问权限,避免恶意代码的访问,保护系统资源。对该系统的兼容性、有效性的测试结果表明,该系统能够为应用程序提供稳定的环境。
关键词:Android;数据安全;细粒度权限管控;访问控制列表机制;系统资源
中图分类号:TP309
文献标志码:A
Android permission management and control scheme based on access control list mechanism
CAO Zhenhuan1, CAI Xiaohai2, GU Menghe3, GU Xiaozhuo2*, LI Xiaowei4
1.Gansu Information Center, Lanzhou Gansu 730030, China;
2.Institute of Information Engineering, Chinese Academy of Sciences, Beijing 100093, China;
3.Northwest Institute of EcoEnvironment and Resources, Chinese Academy of Sciences,Lanzhou Gansu 730030, China;
4.Information Center of Gansu Association for Science and Technology, Lanzhou Gansu 730030, China
Abstract:
Android uses the permissionbased access control method to protect the system resources, which has the problem of rough management. At the same time, some malicious applications can secretly access resources in a privacy scenario without the users permission, bringing certain threats to user privacy and system resources. Based on the original permission management and control and with the introduction of Access Control List (ACL) mechanism, an Android finegrained permission management and control system based on ACL mechanism was designed and implemented. The proposed system can dynamically set the access rights of the applications according to the users policy, avoiding the access of malicious codes to protect system resources. Tests of compatibility and effectiveness show that the system provides a stable environment for applications.
Key words:
Android; information security; finegrained permission control; Access Control List (ACL) mechanism; system resource
0 引言
Android是主流的移動智能终端操作系统, 随着第三方应用程序市场的不断扩大、用户数量的不断增长以及Android应用开发成本相对低等原因,Android成为目前市场占有率最高的移动设备操作系统。移动终端给人们的工作和生活带来了便利,但网络信息安全问题也随之出现。如果开发者对敏感数据不能有效的保护,那么用户可能会面临严重的隐私泄露威胁。随着人们对Android数据安全性要求的提高,Android权限管控机制相关的研究也显得尤为重要。
Android系统继承了Linux系统的诸多优点,但是Android系统目前不支持访问控制列表(Access Control List, ACL)[1]机制。早期版本的Android采用基于权限的访问控制方式对系统资源进行保护。在程序安装时,如果需要申请某一权限可在AndroidManifest.xml文件中使用Usespermission标签申明,包管理器PackageManager负责解析。只有用户同意授权后,此应用程序的安装才开始,一旦用户不同意某种或多种类型的权限,系统将会终止安装。在应用程序成功安装后运行时,系统会根据被授予权限回应程序的敏感操作。Android 6.0 版本引入运行时权限, 运行时权限继承了安装时权限的部分特性,对于危险级别的权限,使用运行时权限策略来处理。运行时权限策略,除了需要在AndroidManifest中显式申请,还需要开发者在代码中用到的地方加入显式的申请的逻辑,这也成为恶意应用程序大肆传播的原因。对于一些恶意代码,能够通过本地代码和JNI(Java Native Interface)技术绕过permission机制的权限检查,如果Android内核层的UGO(User/Group/Others)权限访问机制不能有效管控,应用就能直接访问系统资源。而对于获得root权限的应用程序,它们拥有访问整个系统资源的权限,Android内核层的UGO权限访问机制对于这种应用程序的访问并不起作用,从而给用户隐私和系统资源带来了严重的威胁。
一个安全操作系统必须具有良好的访问控制来控制主体对客体的活动,自主访问控制(Discretionary Access Control, DAC)机制是安全操作系统必不可少的安全机制之一,ACL是非常成熟地实现DAC的有效方法。针对以上问题,通过调研分析,本文提出了基于ACL訪问控制机制的Android细粒度权限管控方案。该方案在原有UGO访问控制的基础上,增加了ACL的权限检查,根据应用程序的UID(User IDentification)动态配置系统资源和管控应用程序的ACL权限。
本文从Android内核、运行时动态库两层入手使其支持ACL权限信息相关设置:对于内核层,重新定制编译内核特性,使ACL权限信息成为文件系统支持的扩展属性之一;对于动态库,移植Linux中ACL访问控制机制相关源码到Android,生成系统动态库供系统其他进程调用。该系统起初调试运行于Android 5.1.1平台,后又在LineageOS Android 8.1.0进行了兼容性测试。添加了新的系统服务,为授权了的应用程序提供执行ACL权限设置相关的API(Application Programming Interface)。为了增加安全性,与权限设置相关的行为通过原本为root权限的zygote执行,系统在zygote中注入调用ACL动态库相关操作和socket通信相关代码,使其能顺利地通过socket和system server进行通信,同时,为了让用户能够动态、方便地根据自己的需求制定特定资源权限访问策略,本系统提供了权限管控中心,该权限管控中心提供系统资源ACL访问权限获取和系统资源ACL访问权限设置的功能。
本文基于ACL访问控制机制的权限管控系统进行了全面的测试,包括系统的兼容性测试、有效性测试和高版本兼容性测试。结果表明该系统能够为应用程序提供稳定的环境。
1 相关工作
1.1 Android权限管控方式
在Android中,权限管控主要有两种方式,位于不同的层面:一种是Android permission机制,位于Android应用框架层; 另一种是基于Linux操作系统的安全机制,位于Android内核层。Android 6.0版本引入运行时权限, 运行时权限授予从安装权限演进而来,对于正常的权限,安装时须在AndroidManifest.xml中显式声明。对于危险权限,不但需要在AndroidManifest.xml中声明,而且还需要用户明确授予,如果设备运行的是Android 6.0或更高版本,并且应用的targetSdkVersion是23或更高版本,则应用在运行时向用户请求权限。如果设备运行的是Andorid 5.1(API级别22)或更低版本,并且应用的targetSdkVersion是22或更低版本,应用程序安装时,系统会将AndroidManifest.xml文件中的permission信息保存在package.xml文件中。程序启动后,就会将package.xml中的权限信息读取至内存中,在APP(Application)进行资源访问时,系统服务调用System Server提供的PermCheck函数对比资源要求的permission许可和内存中的许可,进行访问控制决策。
如果应用程序使用Java API、Android API甚至本地代码的方式触发系统调用访问由Linux内核管理的资源,系统采用内核层Linux的UGO自主访问控制机制管控应用程序的访问,该机制利用UID/GID(Group Identification)机制原理完成权限管控。对于用户在安装时授予应用程序的某个特定权限,系统会将应用程序UID与该权限对应的用户组进行绑定。应用程序启动时,该应用程序就具备了使用该权限的能力,应用程序访问资源时,则会检查该应用UID与资源用户组的关系,判断访问是否合法。
1.2 Android安全机制研究方向
目前研究人员针对Android中基于权限的安全机制的进行研究和改进主要有两个方面:一个是permission机制相关的研究,另一个是内核层的安全增强方案。对于permission机制粗粒度权限管控的问题,研究人员提出了多种permission机制扩展工作,主要通过应用程序APK(AndroidPacKage)的静态分析和运行时权限分析这两种方式。
1.2.1 应用程序安装包静态分析
应用程序安装包静态分析集中在对应用程序申请的permission权限进行静态分析上。APKTool[2]是Android程序逆向分析工具。Stowaway[3]用于检查应用程序是否过度申请permission权限。ScanDroid[4]通过扫描manifest文件并和下载的应用市场中的描述进行对比,判断是否一致。Enck等[5]提出的Kirin服务制定了一套permission组合的策略,此服务的主要功能是安装应用程序时进行轻量级认证,从中发现可能会对个人信息或系统造成危害的潜在威胁。
1.2.2 运行时权限分析
文献[6-8]方案通过运行时对Permission进行细粒度的访问控制,从而加固了permission机制。
针对以上问题,研究者们提出了Apex(Android permission Extension)[6]框架对permission机制的“全是或全否”进行了改进,允许用户有选择性地对应用进行permission授权。TISSA(Taming InformationStealing Smartphone Applications)[7]在Android上实现了隐私模式。Saint[8]是一个为开发者提供的解决方案,它允许开发者在安装或运行时为自己的APP设置安全策略。上述方案依赖于策略数据库,当应用程序获取到root权限后,策略数据库文件能够被篡改或删除,从而影响系统安全。
动态污点分析工具TaintDroid[9]为敏感数据源加上标签,修改Dalvik虚拟机实现对带标签数据的流向追踪,检测是否有数据流出,造成数据泄露。AppFence[10]在TaintDroid的基础上使用伪造的数据来代替真实的数据。VetDroid[11]、 MockDroid[12]通过离线分析不可信的应用程序对permission的使用来发现恶意行为。
1.2.3 内核层安全增强方案
文献[13]研究结论表明部分恶意程序能通过本地代码绕开permission机制,还有些恶意应用程序获取root权限后,拥有访问所有资源的权限。
2010年,Shabtai等[14]提出了以SELinux (SecurityEnhanced Linux) 为内核实现Android安全机制增强的思路,制定了一套细粒度的访问控制方案,但是SELinux的性能损耗比较严重。2011年,Bugiel等[15]以TOMOYO Linux为安全增强内核,开发了TrustDroid[16]系统。为了解决SELinux性能消耗较大的问题,2013年Smalley等[17]实现了基于SELinux 内核的Android 系统,SEAndroid(SecurityEnhanced Android)。上述方案都是在Linux层面上改变了文件的访问控制方式,将原来的自主访问控制DAC转换成为强制访问控制MAC(Mandatory Access Control), 文献[18-20]还有不少针对内核层提出的安全增强方案。
1.3 ACL访问控制机制
ACL是非常成熟的权限管理手段之一,国内外的安全操作系统,如Trusted Xenix、Trusted BSD、IRIX等,都采用ACL提供更细粒度和更灵活方便的自主访问控制。ACL的原理非常简单:每一项资源,都配有一个列表,这个列表记录的就是哪些用户可以对这项资源执行CRUD(Create\Retrieve\Update\Delete)中的哪些操作。当系统试图访问这项资源时,会首先检查这个列表中是否有关于当前用户的访问权限,从而确定当前用户可否执行相应的操作。由于ACL的简单性,使得它几乎不需要任何基础设施就可以完成访问控制。ACL可以对单个用户、单个用户组进行权限细化。ACL机制可以通过setfacl指令设置权限,通过getfacl获得资源权限。设置ACL权限可以使用setfaclm u:user:rwx file或setfaclm g:group:rfile分别表示对用户和组设置访问权限,其中,u表示对用户设置权限,g表示对组设置权限,user可以用用户ID以及用户名来表示,同样group可以使用组ID以及组名来表示,file为客体。获取ACL信息时执行getfacl file指令。获得的ACL权限每一行都是一个ACL实体,所有的ACL实体构成文件的ACL属性。实体由三部分组成,每部分之间使用“:”进行分割。三部分为:
1)e_tag 实体标志:ACL_USER_OBJ、ACL_USER、ACL_GROUP_OBJ、ACL_GROUP、ACL_MASK、ACL_OTHER。
2)e_id:用戶id或组id,即uid或gid。
3)e_perm:访问权限,即rwx。
2 Android中ACL权限管控设计
2.1 Android中基于ACL的细粒度权限管控
本文提出了一种基于Linux中ACL访问控制机制的权限管控方案,该方案能够让用户根据自己的需求制定访问策略,从而减小恶意程序在隐私场景下对资源的滥用带来的风险。
图1描述了本系统中应用程序访问文件等资源时的权限检查流程。在Android中,绕过permission权限检查以及直接访问系统资源的进程,应用会通过Android内核层的UGO自主访问控制的权限检查。首先,系统先进行一般性错误检查,用于检查一些常规的错误;通过该项检查后;再通过进程所在的组的GID来判断是否有权限访问资源,即基于Linux UID/GID的安全检查,就是根据进程所在的组的GID来判断是否有权限访问资源; 最后再判断这些访问是否符合SEAndroid的访问策略。本文提出的改进系统在原有UGO权限检查之后,增加了一个新的ACL访问控制机制的访问权限判断,如图1虚线框中的权限检查。
ACL访问控制机制的引入的意义在于,通过ACL访问权限的开关,可以动态地对资源进行权限管控,只有在通过Linux UID/GID的安全检查后,才会进入到权限检查,而且不受SEAndroid的干预,因为SEAndroid不允许用户对其进行修改。
ACL根据用户UID设置资源访问权限,Android 4.2版本引入多用户模式,每个用户有一个唯一的UserId,每个应用程序都拥有唯一的Application ID(AppId)。UserId+AppId 才等于 Linux 下的UID。在通过UGO检查后,用户再根据自身需求设置应用程序访问资源的权限,该方案是一种细粒度权限管控的方案。
2.2 基于ACL的权限管控系统架构
图2为基于ACL的Android资源访问的权限管控系统的总体框架图,系统主要包含三个模块,分别为:ACL访问控制机制支持、ACL服务模块以及权限管控中心三个模块,图2描述了每个模块大体的结构以及每个模块之间的调用关系。
2.2.1 ACL访问控制机制支持模块
ACL访问控制机制目前主要应用在Linux文件系统的权限管控中,虽然Android内核基于Linux,但是精简过的Android内核对其并不支持。该模块主要的工作就是将Linux 中的ACL访问控制机制从Linux移植到Android中,从而实现对ACL访问控制机制的支持。该模块重新定制了Android内核,使内核层的文件系统支持ACL这一文件扩展属性, 而Android中的函数调用都通过函数库也就是.so的动态库的形式进行调用访问, 因此该模块还对Linux中的ACL动态库源码进行了移植,最终提供一个可调用的动态库作为输出。除此以外,为了验证移植后ACL权限管控的有效性,该模块提供了设置,获取ACL相关的命令行二进制指令。
2.2.2 ACL服务模块
本模块在ACL访问控制机制支持模块基础上,构造了一个ACLService的系统服务,为上层的权限管控中心提供了设置以及获取资源ACL权限的API,同时,调用动态库中与ACL权限相关的函数,对资源的扩展属性进行操作。该模块分别对zygote和system_server进行了注入,使其分别为服务端和客户端进行通信,system_server作为客户端给zygote发送ACLService系统服务中的请求,zygote接收到请求后调用ACL访问控制机制支持模块中动态库相关函数执行操作。为了确保安全性,本系统将执行权限设置相关的函数交由拥有root权限的zygote进行设置,否则会造成普通用户权限过大的问题。
2.2.3 权限管控中心
权限管控中心位于整个系统的最顶层,主要负责与用户进行交互,用户可以在权限管控中心对资源进行管控,同时也可以方便地获取指定资源的访问控制列表。该中心主要有两个功能:一个是权限监管功能,另一个是权限操作功能。权限监管可以实时地获取特定资源的权限信息,查看哪些应用可以对其进行访问。权限监管还能记录对特定资源执行过的所有操作,权限操作功能能够通过发送权限设置请求给ACL服务模块,动态地设置资源权限。在收到服务模块执行请求的结果后,把执行结果反馈给用户。
上述三个模块构成了基于ACL访问控制机制的权限访问系统的主要架构。首先,用户在权限管控中心应用程序中执行设置应用程序访问权限的操作,该操作调用ACLService系统服务中相关API。系统服务中的API通过封装后将资源、权限、应用程序UID等参数传递给system_server,最后system_server通过socket与zygote进行交互。zygote作为服务端接收到来自system_server的消息后,执行权限设置的操作并将执行结果返回到system_server中。ACL访问控制机制支持模块将zygote执行的操作落实到权限管控中。先被使用的ACL动态库会调用Android系统库bionic中与扩展属性相关的函数,再通过系统调用执行内核层中的操作,将ACL权限信息与文件扩展属性联系在一起。给资源设置具体的访问权限之后,每当有应用程序要访问相应的资源时,系统会对通过UGO权限检查的访问进行ACL权限检查,当符合制定的策略时,则通过访问,否则,拒绝访问请求。
2.3 Android内核层ACL支持的实现
fs/posix_acl.c文件实现了POSIX 1003.1e草案中定义的ACL相关操作的通用实现。Linux中ACL权限检查在获取资源的ACL属性后,执行fs/posix_acl.c文件中的posix_acl_permission函数进行ACL权限检查,检查当前进程的UID是否满足文件的ACL属性中的访问限制。ACL是物理文件系统的一个属性,存储在文件系统中,在系统启动后再从外存读取和写入到内存ACL结构中。
本文首先采用5.1.1AOSP(Android Open Source Project)作为实验系统。本文重置配置文件.config中与ACL特性相关的参数。表1列出了原AOSP系统中内核与本文系统内核参数。从表中可以看出,修改的参数都是与文件系统相关的,例如EXT4以及TMPFS。在Android中主要使用EXT4作为其文件系统。编译器根据修改过的配置文件生成新的booting.img,在系统启动后,用新的内核替代已编译的内核。在替换之后,ACL在Android的EXT4文件系统中将会成为文件扩展属性中的一个属性,存储在inode的xattr_entry中,每个文件或者目录都有一个inode用于记录它们的一些信息,例如创建时间、文件类型、访问权限等信息。
2.4 Android中ACL动态库的编译
在Linux中,大多应用以及安装包通过命令的方式进行安装,但是在Android中,没有完整的ACL相关安裝包可以直接用于安装,本节主要工作是将Linux中的ACL相关源码移植到AOSP,这些源码会被编译进Android中C/C++的共享库,供Android系统中不同的组件调用,最终生成定制的系统镜像。
首先,从公开社区下载Linux中运行的‘libacl的动态库源码,由于Linux和Android编译器的不同,需要重构部分‘libacl动态库源码来保证顺利编译。‘libacl的源码整合在MYAOSP/system/core/目录下。源码中总共包含了256个文件,但是大部分并非必要的功能,例如:man指令、chacl指令等,移除这些非必要的功能后,‘libacl的源码目录包含7个头文件,46个C文件以及一个makefile文件,makefile文件定义了一系列的规则来指定文件的编译规则。过多的C文件和头文件混杂在一起导致改写makefile文件过于复杂,因此,本次工作将‘libacl目录中的源码分成头文件和C文件两个目录,头文件再引用ACL相关源码中用到的所有头文件。根据每个C文件实现的功能,将其划分成三种类别,如表2所示,将源码分别整合至这3个文件中,其中:posix functions.c中函数按照IEEE Computer Society标准实现;internal_functions.c文件主要是用于转换ACL权限信息属性和文件扩展属性的内部调用;libacl_functions.c文件则是libacl动态库中导出的相关函数,包括检查ACL信息是否有效等。
Android和Linux采用不同格式的工程编译规则文件,本节重新编写了Android专用的动态库编译规则文件,命名为Android.mk。Android.mk是Android提供的一种makefile文件,专门用来指定诸如编译生成so库名、引用的头文件目录、需要编译的C/C++文件和.a静态库文件等。在编译完成后系统就会生成libacl.so动态库并保存在system/lib目录下,通过2.3节和本节的移植,该系统具备了设置ACL访问控制权限的基本功能。
ACL动态库Android.mk文件为:
程序前
LOCAL_PATH:= $(call mydir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := inner_functions.c libacl_functions.c posix_functions.c misc.c walk_tree.c
LOCAL_MODULE := libacl
LOCAL_MODULE_TAGS := optional
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include
LOCAL_EXPORT_C_INCLUDE_DIRS:= $(LOCAL_PATH)/export
LOCAL_CFLAGS := -Wall
include $(BUILD_SHARED_LIBRARY)
程序后
2.5 system server与zygote的socket通信
本文使用system server作为通信的客户端也是因为system server和zygote之间有可重用的socket通信,在已有的通信开销的基础上进行请求响应尽可能减少了对系统的影响并可以省去创建新连接的开销。
图2详细描述了整个ACL服务模块的实现。首先,在system server中注册一个新的系统服务ACLService,为权限管控中心提供ACL权限相关的接口。zygote和system server通过socket进行通信,zygote创建注册socket后,会对socket进行监听,检查是否有请求进入。zygote调用runSelectLoop()方法对来自system server中ActivityManagerService的请求进行监听(zygote和system server之间的通信专门用于创建进程请求的响应),该方法通过循环的方式检查请求,一旦有来自system server的请求,zygote就会创建一个新的对象ZygoteConnection放入等待请求处理的队列中。最后通过调用一个函数runOnce()进行请求的响应。在该函数中,首先要对请求进行判断,通过分析传入的参数,判断该请求为创建进程的请求,然后调用handleAbiListQuery()函数执行其他的分支。
runOnce()函数修改后代码为:
程序前
boolean runOnce() throws ZygoteInit.MethodAndArgsCaller {
…
try {
parsedArgs=new Arguments(args);
if (parsedArgs.abiListQuery) {
return handleAbiListQuery();
// imbed hook here
if (parsedArgs.execShell != null) {
return ExecuteAclCmd(parsedArgs.execShell);
}
}catch (IOException ex) {
logAndPrintError(newStderr, "Exception creating pipe", ex);
}
}
程序后
本方案在runOnce()函数中注入了一个分支,为了便于判断ACL权限相关的请求,本方案在参数列表parsedArgs中增加了一个新的参数execShell,當execShell为true时,就执行runOnce()函数的封装函数ExecuteAclCmd()。因此,当一个请求来自system server时,可以通过execShell参数来判断该请求是用于创建新进程还是用于执行ACL权限相关的操作。在函数ExecuteAclCmd中调用2.4节编译的libacl.so动态库中相关的函数,再将结果返回给system server。最后,在Process进程中注入handleAcl()函数作为客户端发起权限操作请求的入口。后续对请求参数转化、鉴别参数设置及数据流输入输出转换等功能进行操作。
2.6 SEAndroid权限修改
Android在4.3版本中引入了基于SELinux的SEAndroid安全机制用于加强系统的安全性。SEAndroid安全机制中的安全策略通过主体和客体的安全上下文定义主体是否有权限访问客体。通常,一个策略中包含主体(域)、客体(类型)、操作权限,其中操作权限描述了主体能对客体进行的操作,如读、写、设置文件属性等。
表3分别列出了zygote和system server两个上下文需要额外添加的访问策略。对于每个重要的系统进程,系统都会专门制定一个包含一系列策略强制访问控制策略文件。2.5节中通过zygote对资源执行ACL权限的设置与获取,ACL权限信息的获取与设置涉及到文件系统中文件扩展属性相关的操作,例如setattr、getattr等。在原来的zygote访问控制策略中,并没有允许其执行文件扩展属性相关的操作,因而zygote执行相关操作时,系统会拒绝这些行为。本文在zygote.te文件中加入了表3中策略1和策略2两种策略。本系统在system server中新注册了一个系统服务ACLService,在没有显式指定的情况下,system server中的每一个对象都会有一个默认的 ACL 值,这个值代表了所有的用户对这个对象都是可读可写的。
3 实验与性能评估
前面章节描述了整个系统的设计和实现的要点,本章将对上述的原型系统进行实验分析。为了全面准确地评估该系统,本文从三方面进行评估,分别是应用程序的兼容性、系统的有效性和性能。
3.1 系统环境搭建
本原型系统搭载在Nexus 6上,Nexus 6的主要硬件配置为:高通骁龙 805CPU(2.7GHz,四核)以及3GB内容。Nexus 6中部署Android 5.1.1 r14 tag作为测试版本。在Nexus 6中部署LineageOS Android 8.1.0测试,同样的,原系统也使用部署了Android 5.1.1 r14 tag和LineageOS Android 8.1.0与Nexus 6两个测试版本作对比。
3.2 APP兼容性测试
本文在Google Play商店下载了不同类别的100个热门应用程序作为实验的样本,包括QQ、微信、微博、Chrome浏览器、百度地图、美颜相机等应用程序,其覆盖了社交、摄影与录像、娱乐等类别,用于测试系统对于应用程序的兼容性。实验采用Google Monkey作为测试工具。Monkey是Google研发的一款Android自动化测试工具,它能够运行在任意版本的平台上,自动将伪随机用户事件发送到指定的应用程序, 并帮助测试应用程序是否会崩溃。
为了提高数据的可靠性,先使用人工手段随机地点击20个应用进行测试,检查是否有应用程序闪退的现象发生。接着使用Monkey进行自动化测试,测试工具给每个应用程序发送500个随机用户事件。在这两种检测方式的检测过程中,应用程序都没有出现崩溃的情况。因此,可以得出以下結论:本文提出的权限管控系统对系统稳定性几乎没有影响并兼容绝大部分应用程序。
3.3 系统有效性测试
为了测试系统中ACL权限管控机制的有效性,本文选取了一些重要的系统资源进行测试,包括系统资源如通讯录和短信,设备文件如摄像头、socket等,以及重要的系统文件。表4显示了系统资源及实验结果。
本文对于系统资源以及设备文件采取不同的测试方法。对于设备文件,如socket、前置摄像头以及后置摄像头等,采用单独对应用程序设置权限的方式;而对于调用API访问系统资源方式的资源,本次实验采用关闭所有用户组组访问资源权限的方式来验证其有效性。
应用程序通过建立socket来进行网络访问,本实验通过关闭、开启chrome访问socket的权限来验证ACL权限机制在Android权限管控中的有效性。设置设备文件/dev/socket/dnsproxyd中chrome的ACL访问权限为“”,关闭权限后打开chrome,发现网页显示“net::ERR NAME NOT RESOLVED”的消息,同时查看日志,在日志中发现“permission denied.”的记录。
对于摄像头设备文件,设置UID为10023的美图秀秀访问/dev/video3的权限为“”, /dev/video3文件路径为前置摄像头设备文件句柄。打开美图秀秀使用前置摄像头进行摄像时,前置摄像头启动失败,查看日志文件记录,其中“mm camera open: cannot open control fd of ′/dev/video3′ (Permission denied) ”的记录表明前置摄像头设备文件打开失败。
为了检验本系统动态管控已root应用程序访问系统资源的有效性,本实验对RE应用程序进行root。RE应用程序userId为10053,打开应用程序,进入/data目录后界面列出了该目录下所有的文件。再设置其对该目录的访问权限为x,限制应用程序访问data目录,再次进入data文件夹后显示需要root,同时没有列出该目录相应的文件。
同样地,通过对其他系统资源的验证,表明ACL访问控制机制能够对应用程序访问系统资源起到访问控制的作用,本文实现的权限管控系统具有一定的有效性。
3.4 应用安全性测试
ACL权限管控机制将每个操作授权给特定的 User 用户或者 Role 角色,只允许这些用户或角色对一个对象执行这些操作。在没有显式指定的情况下,system server中的每一个对象都会有一个默认的 ACL 值。这个值代表了所有的用户对这个对象都是可读可写的。一个 User 必须拥有读权限才可以获取一个对象的数据,同时,一个 User 需要写权限才可以更改或者删除一个对象。ACL实现数据级的访问更灵活,能够提高应用系统的安全策略,对系统的变化有更大的伸缩性。下面代码对支持ACL应用的安全性进行了测试。
不使用ACL代码:
程序前
AVObject *post=[AVObject objectWithClassName:@"Post"];
[post setObject:@"Hello" forKey:@"title"];
[post setObject:@"Hello wold!" forKey:@"content"];
[post saveInBackground];
程序后
由于ACL有默认值可读可写,模拟请求后返回请求结果。
程序前
{
"updatedAt":"2019-07-20T09:52:14.137Z",
"objectId":"58705a24128fe1006b275274"}
程序后
请求成功,数据已被修改。因为它的 ACL 值是允许所有人可写可读,所以请求被接受。
使用ACL代码:
程序前
AVObject *post=[AVObject objectWithClassName:@"Post"];
[post setObject:@"Hello" forKey:@"title"];
[post setObject:@"Hello wold!" forKey:@"content"];
AVACL *acl=[AVACL ACL];
[acl setPublicReadAccess:YES];
[acl setWriteAccess:YES forUser:[AVUser currentUser]];
post.ACL=acl;
[post saveInBackground];
程序后
模拟请求后请求结果,请求失败。
程序前
{
"code":1,
"error":"Forbidden writing by objects ACL."
}
程序后
由于 ACL 的值显示该条 Post 只允许一个特定的用户修改,所以请求被拒绝。实验结果表明支持ACL的应用安全性更高。
4 结语
针对Android权限管控不足带来的问题,本文提出了基于ACL访问控制机制的细粒度权限管控方案。该方案在原有UGO访问控制的基础上,引入了Linux中的ACL访问控制机制,在原有UGO权限检查之后,增加了ACL的权限检查,ACL访问控制机制能根据应用程序的UID提供了更加细粒度的权限管控。用户可以动态地设置指定系统资源和应用程序的ACL权限信息,实现权限细粒度管控的功能,從而对系统重要资源和数据起到保护作用,阻止一些使用本地代码的以及获取root权限的应用程序的恶意访问。
本文在实现完整权限管控系统后,对原型系统进行了大量的评估,包括系统对应用程序的兼容性、访问权限管控有效性、支持ACL应用的安全性。测试的结果显示ACL能使数据级的访问更灵活,能够改善应用系统的安全策略,对系统资源起到一定的保护作用。
参考文献 (References)
[1] ACL. ACL(5)Linux man page [EB/OL]. [2019-03-23].http://linux.die.net/man/5/acl.
[2] 尼见. 安卓平台下面向隐私保护的恶意程序分析与检测方法研究[D]. 北京: 北京工业大学, 2017:25-27. (NI J. Privacy protection oriented malicious application analysis and detection method in Android platform[D]. Beijing: Beijing University of Technology, 2017:25-27.)
[3] FELT A P, CHIN E, HANNA S, et al. Android permissions demystified[C]// Proceedings of the 18th ACM Conference on Computer and Communications Security. New York: ACM, 2011: 627-638.
[4] FUCHS A P, CHAUDHURI A, FOSTER J S. SCanDroid: automated security certification of Android applications[EB/OL]. [2019-04-04].https://www.cs.umd.edu/~avik/papers/scandroidascaa.pdf.
[5] ENCK W, ONGTANG M, MCDANIEL P. On lightweight mobile phone application certification[C]// Proceedings of the 16th ACM Conference on Computer and Communications Security. New York: ACM, 2009: 235-245.
[6] NAUMAN M, KHAN S, ZHANG X. Apex: extending Android permission model and enforcement with userdefined runtime constraints[C]// Proceedings of the 5th ACM Symposium on Information, Computer and Communications Security. New York: ACM, 2010:328-332.
[7] ZHOU Y, ZHANG X, JIANG, et al. Taming Information — stealing smartphone applications (on Android)[C]// Proceedings of the 2011 International Conference on Trust and Trustworthy Computing, LNCS 6740. Berlin: Springer, 2011:93-107.
[8] ONGTANG M, MCLAUGHLIN S, ENCK W, et al. Semantically rich applicationcentric security in Android[C]// Proceedings of the 2009 Annual Computer Security Applications Conference. Piscataway: IEEE, 2009:340-349.
[9] ENCK W, GILBERT P, CHUN B G, et al. TaintDroid: an information flow tracking system for realtime privacy monitoring on smartphones[J]. Communications of the ACM, 2014, 57(3):99-106.
[10] HORNYACK P, HAN S, JUNG J, et al. These arent the droids youre looking for: retrofitting Android to protect data from imperious applications[C]// Proceedings of the 18th ACM Conference on Computer and Communications Security. New York: ACM, 2011: 639-652.
[11] ZHANG Y, YANG M, XU B, et al. Vetting undesirable behaviors in Android apps with permission use analysis[C]// Proceedings of the 2013 ACM SIGSAC Conference on Computer and communications security. New York: ACM, 2013:611-622.
[12] BERESFORD A R, RICE A, SKEHIN N, et al. MockDroid: trading privacy for application functionality on smartphones[C]// Proceedings of the 12th Workshop on Mobile Computing Systems and Applications. New York: ACM, 2011: 49-54.
[13] ALLEN G. Android Security and Permissions[M]// Beginning Android. Berkeley, CA: Apress, 2015:343-354.
[14] SHABTAI A, FLEDEL Y, ELOVICI Y. Securing Androidpowered mobile devices using SELinux[J]. IEEE Security and Privacy, 2010, 8(3):36-44.
[15] BUGIEL S, DAVI L, DMITRIENKO A, et al. Practical and lightweight domain isolation on Android[C]// Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices. New York: ACM, 2011:51-62.
[16] ZHAO Z, OSONO F C C. “TrustDroidTM”: preventing the use of smart phones for information leaking in corporate networks through the used of static analysis taint tracking[C]// Proceedings of the 7th International Conference on Malicious and Unwanted Software. Piscataway: IEEE, 2012: 135-143.
[17] SMALLEY S, CRAIG R. Security Enhanced (SE) Android: bringing flexible MAC to Android[EB/OL]. [2019-02-26]. http://www.cs.columbia.edu/~lierranli/coms69987Spring2014/papers/SEAndroidNDSS2013.pdf.
[18] 孫亚楠,石文昌,梁洪亮,等. 安全操作系统基于ACL的自主访问控制机制的设计与实现[J]. 计算机科学, 2004, 31(7):153-155. (SUN Y N, SHI W C, LIANG H L, et al. Design and implementation of ACL based discretionary access control mechanism in secure operation system[J]. Computer Science, 2004, 31(7):153-155.)
[19] 罗琰,张涛,张毓森. Linux环境下访问控制列表机制的设计与实现[J]. 解放军理工大学学报(自然科学版), 2004, 5(3):24-27. (LUO Y, ZHANG T,ZHANG Y S. Design and implementation of access control list mechanism under Linux environment [J]. Journal of PLA University of Science and Technology (Natural Science Edition), 2004, 5(3):24-27.)
[20] AHMED M, AHAMAD M. Protecting health information on mobile devices[C]// Proceedings of the 2nd ACM Conference on Data and Application Security and Privacy. New York: ACM, 2012:229-240.
This work is partially supported by the National Natural Science Foundation of China (61602475), the National Cryptographic Foundation of China (MMJJ20170212), the Gansu Science and Technology Support Project (1504FKCA096).
CAO Zhenhuan, born in 1976, senior engineer. His research interests include network information security.
CAI Xiaohai, born in 1992, M. S. candidate. Her research interests include network security.
GU Menghe, bom in 1974, Ph. D., research assistant. Her research interests include ecological mathematical model.
GU Xiaozhuo, born in 1978, Ph. D., senior engineer. Her research interests include network security protocol.
LI xiaowei, born in 1982, M. S. candidate. His research interests include information project management.