曹震寰 蔡小孩 顧夢(mèng)鶴 顧小卓 李曉偉

摘 要：Android采用基于權(quán)限的訪問(wèn)控制方式對(duì)系統(tǒng)資源進(jìn)行保護(hù)，其權(quán)限管控存在管控力度過(guò)粗的問(wèn)題。同時(shí)，部分惡意程序會(huì)在用戶不知情的情況下，在隱私場(chǎng)景下偷偷地對(duì)資源進(jìn)行訪問(wèn)，給用戶隱私和系統(tǒng)資源帶來(lái)一定的威脅。在原有權(quán)限管控的基礎(chǔ)上引入了訪問(wèn)控制列表（ACL）機(jī)制，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)基于ACL機(jī)制的Android細(xì)粒度權(quán)限管控系統(tǒng)。所提系統(tǒng)能根據(jù)用戶的策略動(dòng)態(tài)地設(shè)置應(yīng)用程序的訪問(wèn)權(quán)限，避免惡意代碼的訪問(wèn)，保護(hù)系統(tǒng)資源。對(duì)該系統(tǒng)的兼容性、有效性的測(cè)試結(jié)果表明，該系統(tǒng)能夠?yàn)閼?yīng)用程序提供穩(wěn)定的環(huán)境。

關(guān)鍵詞：Android;數(shù)據(jù)安全;細(xì)粒度權(quán)限管控;訪問(wèn)控制列表機(jī)制;系統(tǒng)資源

中圖分類號(hào)：TP309

文獻(xiàn)標(biāo)志碼：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是主流的移動(dòng)智能終端操作系統(tǒng)， 隨著第三方應(yīng)用程序市場(chǎng)的不斷擴(kuò)大、用戶數(shù)量的不斷增長(zhǎng)以及Android應(yīng)用開(kāi)發(fā)成本相對(duì)低等原因，Android成為目前市場(chǎng)占有率最高的移動(dòng)設(shè)備操作系統(tǒng)。移動(dòng)終端給人們的工作和生活帶來(lái)了便利，但網(wǎng)絡(luò)信息安全問(wèn)題也隨之出現(xiàn)。如果開(kāi)發(fā)者對(duì)敏感數(shù)據(jù)不能有效的保護(hù)，那么用戶可能會(huì)面臨嚴(yán)重的隱私泄露威脅。隨著人們對(duì)Android數(shù)據(jù)安全性要求的提高，Android權(quán)限管控機(jī)制相關(guān)的研究也顯得尤為重要。

Android系統(tǒng)繼承了Linux系統(tǒng)的諸多優(yōu)點(diǎn)，但是Android系統(tǒng)目前不支持訪問(wèn)控制列表（Access Control List， ACL）[1]機(jī)制。早期版本的Android采用基于權(quán)限的訪問(wèn)控制方式對(duì)系統(tǒng)資源進(jìn)行保護(hù)。在程序安裝時(shí)，如果需要申請(qǐng)某一權(quán)限可在AndroidManifest.xml文件中使用Usespermission標(biāo)簽申明，包管理器PackageManager負(fù)責(zé)解析。只有用戶同意授權(quán)后，此應(yīng)用程序的安裝才開(kāi)始，一旦用戶不同意某種或多種類型的權(quán)限，系統(tǒng)將會(huì)終止安裝。在應(yīng)用程序成功安裝后運(yùn)行時(shí)，系統(tǒng)會(huì)根據(jù)被授予權(quán)限回應(yīng)程序的敏感操作。Android 6.0 版本引入運(yùn)行時(shí)權(quán)限， 運(yùn)行時(shí)權(quán)限繼承了安裝時(shí)權(quán)限的部分特性，對(duì)于危險(xiǎn)級(jí)別的權(quán)限，使用運(yùn)行時(shí)權(quán)限策略來(lái)處理。運(yùn)行時(shí)權(quán)限策略，除了需要在AndroidManifest中顯式申請(qǐng)，還需要開(kāi)發(fā)者在代碼中用到的地方加入顯式的申請(qǐng)的邏輯，這也成為惡意應(yīng)用程序大肆傳播的原因。對(duì)于一些惡意代碼，能夠通過(guò)本地代碼和JNI（Java Native Interface）技術(shù)繞過(guò)permission機(jī)制的權(quán)限檢查，如果Android內(nèi)核層的UGO（User/Group/Others）權(quán)限訪問(wèn)機(jī)制不能有效管控，應(yīng)用就能直接訪問(wèn)系統(tǒng)資源。而對(duì)于獲得root權(quán)限的應(yīng)用程序，它們擁有訪問(wèn)整個(gè)系統(tǒng)資源的權(quán)限，Android內(nèi)核層的UGO權(quán)限訪問(wèn)機(jī)制對(duì)于這種應(yīng)用程序的訪問(wèn)并不起作用，從而給用戶隱私和系統(tǒng)資源帶來(lái)了嚴(yán)重的威脅。

一個(gè)安全操作系統(tǒng)必須具有良好的訪問(wèn)控制來(lái)控制主體對(duì)客體的活動(dòng)，自主訪問(wèn)控制（Discretionary Access Control， DAC）機(jī)制是安全操作系統(tǒng)必不可少的安全機(jī)制之一，ACL是非常成熟地實(shí)現(xiàn)DAC的有效方法。針對(duì)以上問(wèn)題，通過(guò)調(diào)研分析，本文提出了基于ACL訪問(wèn)控制機(jī)制的Android細(xì)粒度權(quán)限管控方案。該方案在原有UGO訪問(wèn)控制的基礎(chǔ)上，增加了ACL的權(quán)限檢查，根據(jù)應(yīng)用程序的UID（User IDentification）動(dòng)態(tài)配置系統(tǒng)資源和管控應(yīng)用程序的ACL權(quán)限。

本文從Android內(nèi)核、運(yùn)行時(shí)動(dòng)態(tài)庫(kù)兩層入手使其支持ACL權(quán)限信息相關(guān)設(shè)置：對(duì)于內(nèi)核層，重新定制編譯內(nèi)核特性，使ACL權(quán)限信息成為文件系統(tǒng)支持的擴(kuò)展屬性之一;對(duì)于動(dòng)態(tài)庫(kù)，移植Linux中ACL訪問(wèn)控制機(jī)制相關(guān)源碼到Android，生成系統(tǒng)動(dòng)態(tài)庫(kù)供系統(tǒng)其他進(jìn)程調(diào)用。該系統(tǒng)起初調(diào)試運(yùn)行于Android 5.1.1平臺(tái)，后又在LineageOS Android 8.1.0進(jìn)行了兼容性測(cè)試。添加了新的系統(tǒng)服務(wù)，為授權(quán)了的應(yīng)用程序提供執(zhí)行ACL權(quán)限設(shè)置相關(guān)的API（Application Programming Interface）。為了增加安全性，與權(quán)限設(shè)置相關(guān)的行為通過(guò)原本為root權(quán)限的zygote執(zhí)行，系統(tǒng)在zygote中注入調(diào)用ACL動(dòng)態(tài)庫(kù)相關(guān)操作和socket通信相關(guān)代碼，使其能順利地通過(guò)socket和system server進(jìn)行通信，同時(shí)，為了讓用戶能夠動(dòng)態(tài)、方便地根據(jù)自己的需求制定特定資源權(quán)限訪問(wèn)策略，本系統(tǒng)提供了權(quán)限管控中心，該權(quán)限管控中心提供系統(tǒng)資源ACL訪問(wèn)權(quán)限獲取和系統(tǒng)資源ACL訪問(wèn)權(quán)限設(shè)置的功能。

本文基于ACL訪問(wèn)控制機(jī)制的權(quán)限管控系統(tǒng)進(jìn)行了全面的測(cè)試，包括系統(tǒng)的兼容性測(cè)試、有效性測(cè)試和高版本兼容性測(cè)試。結(jié)果表明該系統(tǒng)能夠?yàn)閼?yīng)用程序提供穩(wěn)定的環(huán)境。

1?相關(guān)工作

1.1?Android權(quán)限管控方式

在Android中，權(quán)限管控主要有兩種方式，位于不同的層面：一種是Android permission機(jī)制，位于Android應(yīng)用框架層; 另一種是基于Linux操作系統(tǒng)的安全機(jī)制，位于Android內(nèi)核層。Android 6.0版本引入運(yùn)行時(shí)權(quán)限， 運(yùn)行時(shí)權(quán)限授予從安裝權(quán)限演進(jìn)而來(lái)，對(duì)于正常的權(quán)限，安裝時(shí)須在AndroidManifest.xml中顯式聲明。對(duì)于危險(xiǎn)權(quán)限，不但需要在AndroidManifest.xml中聲明，而且還需要用戶明確授予，如果設(shè)備運(yùn)行的是Android 6.0或更高版本，并且應(yīng)用的targetSdkVersion是23或更高版本，則應(yīng)用在運(yùn)行時(shí)向用戶請(qǐng)求權(quán)限。如果設(shè)備運(yùn)行的是Andorid 5.1（API級(jí)別22）或更低版本，并且應(yīng)用的targetSdkVersion是22或更低版本，應(yīng)用程序安裝時(shí)，系統(tǒng)會(huì)將AndroidManifest.xml文件中的permission信息保存在package.xml文件中。程序啟動(dòng)后，就會(huì)將package.xml中的權(quán)限信息讀取至內(nèi)存中，在APP（Application）進(jìn)行資源訪問(wèn)時(shí)，系統(tǒng)服務(wù)調(diào)用System Server提供的PermCheck函數(shù)對(duì)比資源要求的permission許可和內(nèi)存中的許可，進(jìn)行訪問(wèn)控制決策。

如果應(yīng)用程序使用Java API、Android API甚至本地代碼的方式觸發(fā)系統(tǒng)調(diào)用訪問(wèn)由Linux內(nèi)核管理的資源，系統(tǒng)采用內(nèi)核層Linux的UGO自主訪問(wèn)控制機(jī)制管控應(yīng)用程序的訪問(wèn)，該機(jī)制利用UID/GID（Group Identification）機(jī)制原理完成權(quán)限管控。對(duì)于用戶在安裝時(shí)授予應(yīng)用程序的某個(gè)特定權(quán)限，系統(tǒng)會(huì)將應(yīng)用程序UID與該權(quán)限對(duì)應(yīng)的用戶組進(jìn)行綁定。應(yīng)用程序啟動(dòng)時(shí)，該應(yīng)用程序就具備了使用該權(quán)限的能力，應(yīng)用程序訪問(wèn)資源時(shí)，則會(huì)檢查該應(yīng)用UID與資源用戶組的關(guān)系，判斷訪問(wèn)是否合法。

1.2?Android安全機(jī)制研究方向

目前研究人員針對(duì)Android中基于權(quán)限的安全機(jī)制的進(jìn)行研究和改進(jìn)主要有兩個(gè)方面：一個(gè)是permission機(jī)制相關(guān)的研究，另一個(gè)是內(nèi)核層的安全增強(qiáng)方案。對(duì)于permission機(jī)制粗粒度權(quán)限管控的問(wèn)題，研究人員提出了多種permission機(jī)制擴(kuò)展工作，主要通過(guò)應(yīng)用程序APK（AndroidPacKage）的靜態(tài)分析和運(yùn)行時(shí)權(quán)限分析這兩種方式。

1.2.1?應(yīng)用程序安裝包靜態(tài)分析

應(yīng)用程序安裝包靜態(tài)分析集中在對(duì)應(yīng)用程序申請(qǐng)的permission權(quán)限進(jìn)行靜態(tài)分析上。APKTool[2]是Android程序逆向分析工具。Stowaway[3]用于檢查應(yīng)用程序是否過(guò)度申請(qǐng)permission權(quán)限。ScanDroid[4]通過(guò)掃描manifest文件并和下載的應(yīng)用市場(chǎng)中的描述進(jìn)行對(duì)比，判斷是否一致。Enck等[5]提出的Kirin服務(wù)制定了一套permission組合的策略，此服務(wù)的主要功能是安裝應(yīng)用程序時(shí)進(jìn)行輕量級(jí)認(rèn)證，從中發(fā)現(xiàn)可能會(huì)對(duì)個(gè)人信息或系統(tǒng)造成危害的潛在威脅。

1.2.2?運(yùn)行時(shí)權(quán)限分析

文獻(xiàn)[6-8]方案通過(guò)運(yùn)行時(shí)對(duì)Permission進(jìn)行細(xì)粒度的訪問(wèn)控制，從而加固了permission機(jī)制。

針對(duì)以上問(wèn)題，研究者們提出了Apex（Android permission Extension）[6]框架對(duì)permission機(jī)制的“全是或全否”進(jìn)行了改進(jìn)，允許用戶有選擇性地對(duì)應(yīng)用進(jìn)行permission授權(quán)。TISSA（Taming InformationStealing Smartphone Applications）[7]在Android上實(shí)現(xiàn)了隱私模式。Saint[8]是一個(gè)為開(kāi)發(fā)者提供的解決方案，它允許開(kāi)發(fā)者在安裝或運(yùn)行時(shí)為自己的APP設(shè)置安全策略。上述方案依賴于策略數(shù)據(jù)庫(kù)，當(dāng)應(yīng)用程序獲取到root權(quán)限后，策略數(shù)據(jù)庫(kù)文件能夠被篡改或刪除，從而影響系統(tǒng)安全。

動(dòng)態(tài)污點(diǎn)分析工具TaintDroid[9]為敏感數(shù)據(jù)源加上標(biāo)簽，修改Dalvik虛擬機(jī)實(shí)現(xiàn)對(duì)帶標(biāo)簽數(shù)據(jù)的流向追蹤，檢測(cè)是否有數(shù)據(jù)流出，造成數(shù)據(jù)泄露。AppFence[10]在TaintDroid的基礎(chǔ)上使用偽造的數(shù)據(jù)來(lái)代替真實(shí)的數(shù)據(jù)。VetDroid[11]、 MockDroid[12]通過(guò)離線分析不可信的應(yīng)用程序?qū)ermission的使用來(lái)發(fā)現(xiàn)惡意行為。

1.2.3?內(nèi)核層安全增強(qiáng)方案

文獻(xiàn)[13]研究結(jié)論表明部分惡意程序能通過(guò)本地代碼繞開(kāi)permission機(jī)制，還有些惡意應(yīng)用程序獲取root權(quán)限后，擁有訪問(wèn)所有資源的權(quán)限。

2010年，Shabtai等[14]提出了以SELinux （SecurityEnhanced Linux） 為內(nèi)核實(shí)現(xiàn)Android安全機(jī)制增強(qiáng)的思路，制定了一套細(xì)粒度的訪問(wèn)控制方案，但是SELinux的性能損耗比較嚴(yán)重。2011年，Bugiel等[15]以TOMOYO Linux為安全增強(qiáng)內(nèi)核，開(kāi)發(fā)了TrustDroid[16]系統(tǒng)。為了解決SELinux性能消耗較大的問(wèn)題，2013年Smalley等[17]實(shí)現(xiàn)了基于SELinux 內(nèi)核的Android 系統(tǒng)，SEAndroid（SecurityEnhanced Android）。上述方案都是在Linux層面上改變了文件的訪問(wèn)控制方式，將原來(lái)的自主訪問(wèn)控制DAC轉(zhuǎn)換成為強(qiáng)制訪問(wèn)控制MAC（Mandatory Access Control）， 文獻(xiàn)[18-20]還有不少針對(duì)內(nèi)核層提出的安全增強(qiáng)方案。

1.3?ACL訪問(wèn)控制機(jī)制

ACL是非常成熟的權(quán)限管理手段之一，國(guó)內(nèi)外的安全操作系統(tǒng)，如Trusted Xenix、Trusted BSD、IRIX等，都采用ACL提供更細(xì)粒度和更靈活方便的自主訪問(wèn)控制。ACL的原理非常簡(jiǎn)單：每一項(xiàng)資源，都配有一個(gè)列表，這個(gè)列表記錄的就是哪些用戶可以對(duì)這項(xiàng)資源執(zhí)行CRUD（Create＼Retrieve＼Update＼Delete）中的哪些操作。當(dāng)系統(tǒng)試圖訪問(wèn)這項(xiàng)資源時(shí)，會(huì)首先檢查這個(gè)列表中是否有關(guān)于當(dāng)前用戶的訪問(wèn)權(quán)限，從而確定當(dāng)前用戶可否執(zhí)行相應(yīng)的操作。由于ACL的簡(jiǎn)單性，使得它幾乎不需要任何基礎(chǔ)設(shè)施就可以完成訪問(wèn)控制。ACL可以對(duì)單個(gè)用戶、單個(gè)用戶組進(jìn)行權(quán)限細(xì)化。ACL機(jī)制可以通過(guò)setfacl指令設(shè)置權(quán)限，通過(guò)getfacl獲得資源權(quán)限。設(shè)置ACL權(quán)限可以使用setfaclm u：user：rwx file或setfaclm g：group：rfile分別表示對(duì)用戶和組設(shè)置訪問(wèn)權(quán)限，其中，u表示對(duì)用戶設(shè)置權(quán)限，g表示對(duì)組設(shè)置權(quán)限，user可以用用戶ID以及用戶名來(lái)表示，同樣group可以使用組ID以及組名來(lái)表示，file為客體。獲取ACL信息時(shí)執(zhí)行g(shù)etfacl file指令。獲得的ACL權(quán)限每一行都是一個(gè)ACL實(shí)體，所有的ACL實(shí)體構(gòu)成文件的ACL屬性。實(shí)體由三部分組成，每部分之間使用“：”進(jìn)行分割。三部分為：

1）e_tag 實(shí)體標(biāo)志：ACL_USER_OBJ、ACL_USER、ACL_GROUP_OBJ、ACL_GROUP、ACL_MASK、ACL_OTHER。

2）e_id：用戶id或組id，即uid或gid。

3）e_perm：訪問(wèn)權(quán)限，即rwx。

2?Android中ACL權(quán)限管控設(shè)計(jì)

2.1?Android中基于ACL的細(xì)粒度權(quán)限管控

本文提出了一種基于Linux中ACL訪問(wèn)控制機(jī)制的權(quán)限管控方案，該方案能夠讓用戶根據(jù)自己的需求制定訪問(wèn)策略，從而減小惡意程序在隱私場(chǎng)景下對(duì)資源的濫用帶來(lái)的風(fēng)險(xiǎn)。

圖1描述了本系統(tǒng)中應(yīng)用程序訪問(wèn)文件等資源時(shí)的權(quán)限檢查流程。在Android中，繞過(guò)permission權(quán)限檢查以及直接訪問(wèn)系統(tǒng)資源的進(jìn)程，應(yīng)用會(huì)通過(guò)Android內(nèi)核層的UGO自主訪問(wèn)控制的權(quán)限檢查。首先，系統(tǒng)先進(jìn)行一般性錯(cuò)誤檢查，用于檢查一些常規(guī)的錯(cuò)誤;通過(guò)該項(xiàng)檢查后;再通過(guò)進(jìn)程所在的組的GID來(lái)判斷是否有權(quán)限訪問(wèn)資源，即基于Linux UID/GID的安全檢查，就是根據(jù)進(jìn)程所在的組的GID來(lái)判斷是否有權(quán)限訪問(wèn)資源; 最后再判斷這些訪問(wèn)是否符合SEAndroid的訪問(wèn)策略。本文提出的改進(jìn)系統(tǒng)在原有UGO權(quán)限檢查之后，增加了一個(gè)新的ACL訪問(wèn)控制機(jī)制的訪問(wèn)權(quán)限判斷，如圖1虛線框中的權(quán)限檢查。

ACL訪問(wèn)控制機(jī)制的引入的意義在于，通過(guò)ACL訪問(wèn)權(quán)限的開(kāi)關(guān)，可以動(dòng)態(tài)地對(duì)資源進(jìn)行權(quán)限管控，只有在通過(guò)Linux UID/GID的安全檢查后，才會(huì)進(jìn)入到權(quán)限檢查，而且不受SEAndroid的干預(yù)，因?yàn)镾EAndroid不允許用戶對(duì)其進(jìn)行修改。

ACL根據(jù)用戶UID設(shè)置資源訪問(wèn)權(quán)限，Android 4.2版本引入多用戶模式，每個(gè)用戶有一個(gè)唯一的UserId，每個(gè)應(yīng)用程序都擁有唯一的Application ID（AppId）。UserId+AppId 才等于 Linux 下的UID。在通過(guò)UGO檢查后，用戶再根據(jù)自身需求設(shè)置應(yīng)用程序訪問(wèn)資源的權(quán)限，該方案是一種細(xì)粒度權(quán)限管控的方案。

2.2?基于ACL的權(quán)限管控系統(tǒng)架構(gòu)

圖2為基于ACL的Android資源訪問(wèn)的權(quán)限管控系統(tǒng)的總體框架圖，系統(tǒng)主要包含三個(gè)模塊，分別為：ACL訪問(wèn)控制機(jī)制支持、ACL服務(wù)模塊以及權(quán)限管控中心三個(gè)模塊，圖2描述了每個(gè)模塊大體的結(jié)構(gòu)以及每個(gè)模塊之間的調(diào)用關(guān)系。

2.2.1?ACL訪問(wèn)控制機(jī)制支持模塊

ACL訪問(wèn)控制機(jī)制目前主要應(yīng)用在Linux文件系統(tǒng)的權(quán)限管控中，雖然Android內(nèi)核基于Linux，但是精簡(jiǎn)過(guò)的Android內(nèi)核對(duì)其并不支持。該模塊主要的工作就是將Linux 中的ACL訪問(wèn)控制機(jī)制從Linux移植到Android中，從而實(shí)現(xiàn)對(duì)ACL訪問(wèn)控制機(jī)制的支持。該模塊重新定制了Android內(nèi)核，使內(nèi)核層的文件系統(tǒng)支持ACL這一文件擴(kuò)展屬性， 而Android中的函數(shù)調(diào)用都通過(guò)函數(shù)庫(kù)也就是.so的動(dòng)態(tài)庫(kù)的形式進(jìn)行調(diào)用訪問(wèn)， 因此該模塊還對(duì)Linux中的ACL動(dòng)態(tài)庫(kù)源碼進(jìn)行了移植，最終提供一個(gè)可調(diào)用的動(dòng)態(tài)庫(kù)作為輸出。除此以外，為了驗(yàn)證移植后ACL權(quán)限管控的有效性，該模塊提供了設(shè)置，獲取ACL相關(guān)的命令行二進(jìn)制指令。

2.2.2?ACL服務(wù)模塊

本模塊在ACL訪問(wèn)控制機(jī)制支持模塊基礎(chǔ)上，構(gòu)造了一個(gè)ACLService的系統(tǒng)服務(wù)，為上層的權(quán)限管控中心提供了設(shè)置以及獲取資源ACL權(quán)限的API，同時(shí)，調(diào)用動(dòng)態(tài)庫(kù)中與ACL權(quán)限相關(guān)的函數(shù)，對(duì)資源的擴(kuò)展屬性進(jìn)行操作。該模塊分別對(duì)zygote和system_server進(jìn)行了注入，使其分別為服務(wù)端和客戶端進(jìn)行通信，system_server作為客戶端給zygote發(fā)送ACLService系統(tǒng)服務(wù)中的請(qǐng)求，zygote接收到請(qǐng)求后調(diào)用ACL訪問(wèn)控制機(jī)制支持模塊中動(dòng)態(tài)庫(kù)相關(guān)函數(shù)執(zhí)行操作。為了確保安全性，本系統(tǒng)將執(zhí)行權(quán)限設(shè)置相關(guān)的函數(shù)交由擁有root權(quán)限的zygote進(jìn)行設(shè)置，否則會(huì)造成普通用戶權(quán)限過(guò)大的問(wèn)題。

2.2.3?權(quán)限管控中心

權(quán)限管控中心位于整個(gè)系統(tǒng)的最頂層，主要負(fù)責(zé)與用戶進(jìn)行交互，用戶可以在權(quán)限管控中心對(duì)資源進(jìn)行管控，同時(shí)也可以方便地獲取指定資源的訪問(wèn)控制列表。該中心主要有兩個(gè)功能：一個(gè)是權(quán)限監(jiān)管功能，另一個(gè)是權(quán)限操作功能。權(quán)限監(jiān)管可以實(shí)時(shí)地獲取特定資源的權(quán)限信息，查看哪些應(yīng)用可以對(duì)其進(jìn)行訪問(wèn)。權(quán)限監(jiān)管還能記錄對(duì)特定資源執(zhí)行過(guò)的所有操作，權(quán)限操作功能能夠通過(guò)發(fā)送權(quán)限設(shè)置請(qǐng)求給ACL服務(wù)模塊，動(dòng)態(tài)地設(shè)置資源權(quán)限。在收到服務(wù)模塊執(zhí)行請(qǐng)求的結(jié)果后，把執(zhí)行結(jié)果反饋給用戶。

上述三個(gè)模塊構(gòu)成了基于ACL訪問(wèn)控制機(jī)制的權(quán)限訪問(wèn)系統(tǒng)的主要架構(gòu)。首先，用戶在權(quán)限管控中心應(yīng)用程序中執(zhí)行設(shè)置應(yīng)用程序訪問(wèn)權(quán)限的操作，該操作調(diào)用ACLService系統(tǒng)服務(wù)中相關(guān)API。系統(tǒng)服務(wù)中的API通過(guò)封裝后將資源、權(quán)限、應(yīng)用程序UID等參數(shù)傳遞給system_server，最后system_server通過(guò)socket與zygote進(jìn)行交互。zygote作為服務(wù)端接收到來(lái)自system_server的消息后，執(zhí)行權(quán)限設(shè)置的操作并將執(zhí)行結(jié)果返回到system_server中。ACL訪問(wèn)控制機(jī)制支持模塊將zygote執(zhí)行的操作落實(shí)到權(quán)限管控中。先被使用的ACL動(dòng)態(tài)庫(kù)會(huì)調(diào)用Android系統(tǒng)庫(kù)bionic中與擴(kuò)展屬性相關(guān)的函數(shù)，再通過(guò)系統(tǒng)調(diào)用執(zhí)行內(nèi)核層中的操作，將ACL權(quán)限信息與文件擴(kuò)展屬性聯(lián)系在一起。給資源設(shè)置具體的訪問(wèn)權(quán)限之后，每當(dāng)有應(yīng)用程序要訪問(wèn)相應(yīng)的資源時(shí)，系統(tǒng)會(huì)對(duì)通過(guò)UGO權(quán)限檢查的訪問(wèn)進(jìn)行ACL權(quán)限檢查，當(dāng)符合制定的策略時(shí)，則通過(guò)訪問(wèn)，否則，拒絕訪問(wèn)請(qǐng)求。

2.3?Android內(nèi)核層ACL支持的實(shí)現(xiàn)

fs/posix_acl.c文件實(shí)現(xiàn)了POSIX 1003.1e草案中定義的ACL相關(guān)操作的通用實(shí)現(xiàn)。Linux中ACL權(quán)限檢查在獲取資源的ACL屬性后，執(zhí)行fs/posix_acl.c文件中的posix_acl_permission函數(shù)進(jìn)行ACL權(quán)限檢查，檢查當(dāng)前進(jìn)程的UID是否滿足文件的ACL屬性中的訪問(wèn)限制。ACL是物理文件系統(tǒng)的一個(gè)屬性，存儲(chǔ)在文件系統(tǒng)中，在系統(tǒng)啟動(dòng)后再?gòu)耐獯孀x取和寫入到內(nèi)存ACL結(jié)構(gòu)中。

本文首先采用5.1.1AOSP（Android Open Source Project）作為實(shí)驗(yàn)系統(tǒng)。本文重置配置文件.config中與ACL特性相關(guān)的參數(shù)。表1列出了原AOSP系統(tǒng)中內(nèi)核與本文系統(tǒng)內(nèi)核參數(shù)。從表中可以看出，修改的參數(shù)都是與文件系統(tǒng)相關(guān)的，例如EXT4以及TMPFS。在Android中主要使用EXT4作為其文件系統(tǒng)。編譯器根據(jù)修改過(guò)的配置文件生成新的booting.img，在系統(tǒng)啟動(dòng)后，用新的內(nèi)核替代已編譯的內(nèi)核。在替換之后，ACL在Android的EXT4文件系統(tǒng)中將會(huì)成為文件擴(kuò)展屬性中的一個(gè)屬性，存儲(chǔ)在inode的xattr_entry中，每個(gè)文件或者目錄都有一個(gè)inode用于記錄它們的一些信息，例如創(chuàng)建時(shí)間、文件類型、訪問(wèn)權(quán)限等信息。

2.4?Android中ACL動(dòng)態(tài)庫(kù)的編譯

在Linux中，大多應(yīng)用以及安裝包通過(guò)命令的方式進(jìn)行安裝，但是在Android中，沒(méi)有完整的ACL相關(guān)安裝包可以直接用于安裝，本節(jié)主要工作是將Linux中的ACL相關(guān)源碼移植到AOSP，這些源碼會(huì)被編譯進(jìn)Android中C/C++的共享庫(kù)，供Android系統(tǒng)中不同的組件調(diào)用，最終生成定制的系統(tǒng)鏡像。

首先，從公開(kāi)社區(qū)下載Linux中運(yùn)行的‘libacl的動(dòng)態(tài)庫(kù)源碼，由于Linux和Android編譯器的不同，需要重構(gòu)部分‘libacl動(dòng)態(tài)庫(kù)源碼來(lái)保證順利編譯。‘libacl的源碼整合在MYAOSP/system/core/目錄下。源碼中總共包含了256個(gè)文件，但是大部分并非必要的功能，例如：man指令、chacl指令等，移除這些非必要的功能后，‘libacl的源碼目錄包含7個(gè)頭文件，46個(gè)C文件以及一個(gè)makefile文件，makefile文件定義了一系列的規(guī)則來(lái)指定文件的編譯規(guī)則。過(guò)多的C文件和頭文件混雜在一起導(dǎo)致改寫makefile文件過(guò)于復(fù)雜，因此，本次工作將‘libacl目錄中的源碼分成頭文件和C文件兩個(gè)目錄，頭文件再引用ACL相關(guān)源碼中用到的所有頭文件。根據(jù)每個(gè)C文件實(shí)現(xiàn)的功能，將其劃分成三種類別，如表2所示，將源碼分別整合至這3個(gè)文件中，其中：posix functions.c中函數(shù)按照IEEE Computer Society標(biāo)準(zhǔn)實(shí)現(xiàn);internal_functions.c文件主要是用于轉(zhuǎn)換ACL權(quán)限信息屬性和文件擴(kuò)展屬性的內(nèi)部調(diào)用;libacl_functions.c文件則是libacl動(dòng)態(tài)庫(kù)中導(dǎo)出的相關(guān)函數(shù)，包括檢查ACL信息是否有效等。

Android和Linux采用不同格式的工程編譯規(guī)則文件，本節(jié)重新編寫了Android專用的動(dòng)態(tài)庫(kù)編譯規(guī)則文件，命名為Android.mk。Android.mk是Android提供的一種makefile文件，專門用來(lái)指定諸如編譯生成so庫(kù)名、引用的頭文件目錄、需要編譯的C/C++文件和.a靜態(tài)庫(kù)文件等。在編譯完成后系統(tǒng)就會(huì)生成libacl.so動(dòng)態(tài)庫(kù)并保存在system/lib目錄下，通過(guò)2.3節(jié)和本節(jié)的移植，該系統(tǒng)具備了設(shè)置ACL訪問(wèn)控制權(quán)限的基本功能。

ACL動(dòng)態(tài)庫(kù)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作為通信的客戶端也是因?yàn)閟ystem server和zygote之間有可重用的socket通信，在已有的通信開(kāi)銷的基礎(chǔ)上進(jìn)行請(qǐng)求響應(yīng)盡可能減少了對(duì)系統(tǒng)的影響并可以省去創(chuàng)建新連接的開(kāi)銷。

圖2詳細(xì)描述了整個(gè)ACL服務(wù)模塊的實(shí)現(xiàn)。首先，在system server中注冊(cè)一個(gè)新的系統(tǒng)服務(wù)ACLService，為權(quán)限管控中心提供ACL權(quán)限相關(guān)的接口。zygote和system server通過(guò)socket進(jìn)行通信，zygote創(chuàng)建注冊(cè)socket后，會(huì)對(duì)socket進(jìn)行監(jiān)聽(tīng)，檢查是否有請(qǐng)求進(jìn)入。zygote調(diào)用runSelectLoop（）方法對(duì)來(lái)自system server中ActivityManagerService的請(qǐng)求進(jìn)行監(jiān)聽(tīng)（zygote和system server之間的通信專門用于創(chuàng)建進(jìn)程請(qǐng)求的響應(yīng)），該方法通過(guò)循環(huán)的方式檢查請(qǐng)求，一旦有來(lái)自system server的請(qǐng)求，zygote就會(huì)創(chuàng)建一個(gè)新的對(duì)象ZygoteConnection放入等待請(qǐng)求處理的隊(duì)列中。最后通過(guò)調(diào)用一個(gè)函數(shù)runOnce（）進(jìn)行請(qǐng)求的響應(yīng)。在該函數(shù)中，首先要對(duì)請(qǐng)求進(jìn)行判斷，通過(guò)分析傳入的參數(shù)，判斷該請(qǐng)求為創(chuàng)建進(jìn)程的請(qǐng)求，然后調(diào)用handleAbiListQuery（）函數(shù)執(zhí)行其他的分支。

runOnce（）函數(shù)修改后代碼為：

程序前

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（）函數(shù)中注入了一個(gè)分支，為了便于判斷ACL權(quán)限相關(guān)的請(qǐng)求，本方案在參數(shù)列表parsedArgs中增加了一個(gè)新的參數(shù)execShell，當(dāng)execShell為true時(shí)，就執(zhí)行runOnce（）函數(shù)的封裝函數(shù)ExecuteAclCmd（）。因此，當(dāng)一個(gè)請(qǐng)求來(lái)自system server時(shí)，可以通過(guò)execShell參數(shù)來(lái)判斷該請(qǐng)求是用于創(chuàng)建新進(jìn)程還是用于執(zhí)行ACL權(quán)限相關(guān)的操作。在函數(shù)ExecuteAclCmd中調(diào)用2.4節(jié)編譯的libacl.so動(dòng)態(tài)庫(kù)中相關(guān)的函數(shù)，再將結(jié)果返回給system server。最后，在Process進(jìn)程中注入handleAcl（）函數(shù)作為客戶端發(fā)起權(quán)限操作請(qǐng)求的入口。后續(xù)對(duì)請(qǐng)求參數(shù)轉(zhuǎn)化、鑒別參數(shù)設(shè)置及數(shù)據(jù)流輸入輸出轉(zhuǎn)換等功能進(jìn)行操作。

2.6?SEAndroid權(quán)限修改

Android在4.3版本中引入了基于SELinux的SEAndroid安全機(jī)制用于加強(qiáng)系統(tǒng)的安全性。SEAndroid安全機(jī)制中的安全策略通過(guò)主體和客體的安全上下文定義主體是否有權(quán)限訪問(wèn)客體。通常，一個(gè)策略中包含主體（域）、客體（類型）、操作權(quán)限，其中操作權(quán)限描述了主體能對(duì)客體進(jìn)行的操作，如讀、寫、設(shè)置文件屬性等。

表3分別列出了zygote和system server兩個(gè)上下文需要額外添加的訪問(wèn)策略。對(duì)于每個(gè)重要的系統(tǒng)進(jìn)程，系統(tǒng)都會(huì)專門制定一個(gè)包含一系列策略強(qiáng)制訪問(wèn)控制策略文件。2.5節(jié)中通過(guò)zygote對(duì)資源執(zhí)行ACL權(quán)限的設(shè)置與獲取，ACL權(quán)限信息的獲取與設(shè)置涉及到文件系統(tǒng)中文件擴(kuò)展屬性相關(guān)的操作，例如setattr、getattr等。在原來(lái)的zygote訪問(wèn)控制策略中，并沒(méi)有允許其執(zhí)行文件擴(kuò)展屬性相關(guān)的操作，因而zygote執(zhí)行相關(guān)操作時(shí)，系統(tǒng)會(huì)拒絕這些行為。本文在zygote.te文件中加入了表3中策略1和策略2兩種策略。本系統(tǒng)在system server中新注冊(cè)了一個(gè)系統(tǒng)服務(wù)ACLService，在沒(méi)有顯式指定的情況下，system server中的每一個(gè)對(duì)象都會(huì)有一個(gè)默認(rèn)的 ACL 值，這個(gè)值代表了所有的用戶對(duì)這個(gè)對(duì)象都是可讀可寫的。

3?實(shí)驗(yàn)與性能評(píng)估

前面章節(jié)描述了整個(gè)系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)的要點(diǎn)，本章將對(duì)上述的原型系統(tǒng)進(jìn)行實(shí)驗(yàn)分析。為了全面準(zhǔn)確地評(píng)估該系統(tǒng)，本文從三方面進(jìn)行評(píng)估，分別是應(yīng)用程序的兼容性、系統(tǒng)的有效性和性能。

3.1?系統(tǒng)環(huán)境搭建

本原型系統(tǒng)搭載在Nexus 6上，Nexus 6的主要硬件配置為：高通驍龍 805CPU（2.7GHz，四核）以及3GB內(nèi)容。Nexus 6中部署Android 5.1.1 r14 tag作為測(cè)試版本。在Nexus 6中部署LineageOS Android 8.1.0測(cè)試，同樣的，原系統(tǒng)也使用部署了Android 5.1.1 r14 tag和LineageOS Android 8.1.0與Nexus 6兩個(gè)測(cè)試版本作對(duì)比。

3.2?APP兼容性測(cè)試

本文在Google Play商店下載了不同類別的100個(gè)熱門應(yīng)用程序作為實(shí)驗(yàn)的樣本，包括QQ、微信、微博、Chrome瀏覽器、百度地圖、美顏相機(jī)等應(yīng)用程序，其覆蓋了社交、攝影與錄像、娛樂(lè)等類別，用于測(cè)試系統(tǒng)對(duì)于應(yīng)用程序的兼容性。實(shí)驗(yàn)采用Google Monkey作為測(cè)試工具。Monkey是Google研發(fā)的一款A(yù)ndroid自動(dòng)化測(cè)試工具，它能夠運(yùn)行在任意版本的平臺(tái)上，自動(dòng)將偽隨機(jī)用戶事件發(fā)送到指定的應(yīng)用程序， 并幫助測(cè)試應(yīng)用程序是否會(huì)崩潰。

為了提高數(shù)據(jù)的可靠性，先使用人工手段隨機(jī)地點(diǎn)擊20個(gè)應(yīng)用進(jìn)行測(cè)試，檢查是否有應(yīng)用程序閃退的現(xiàn)象發(fā)生。接著使用Monkey進(jìn)行自動(dòng)化測(cè)試，測(cè)試工具給每個(gè)應(yīng)用程序發(fā)送500個(gè)隨機(jī)用戶事件。在這兩種檢測(cè)方式的檢測(cè)過(guò)程中，應(yīng)用程序都沒(méi)有出現(xiàn)崩潰的情況。因此，可以得出以下結(jié)論：本文提出的權(quán)限管控系統(tǒng)對(duì)系統(tǒng)穩(wěn)定性幾乎沒(méi)有影響并兼容絕大部分應(yīng)用程序。

3.3?系統(tǒng)有效性測(cè)試

為了測(cè)試系統(tǒng)中ACL權(quán)限管控機(jī)制的有效性，本文選取了一些重要的系統(tǒng)資源進(jìn)行測(cè)試，包括系統(tǒng)資源如通訊錄和短信，設(shè)備文件如攝像頭、socket等，以及重要的系統(tǒng)文件。表4顯示了系統(tǒng)資源及實(shí)驗(yàn)結(jié)果。

本文對(duì)于系統(tǒng)資源以及設(shè)備文件采取不同的測(cè)試方法。對(duì)于設(shè)備文件，如socket、前置攝像頭以及后置攝像頭等，采用單獨(dú)對(duì)應(yīng)用程序設(shè)置權(quán)限的方式;而對(duì)于調(diào)用API訪問(wèn)系統(tǒng)資源方式的資源，本次實(shí)驗(yàn)采用關(guān)閉所有用戶組組訪問(wèn)資源權(quán)限的方式來(lái)驗(yàn)證其有效性。

應(yīng)用程序通過(guò)建立socket來(lái)進(jìn)行網(wǎng)絡(luò)訪問(wèn)，本實(shí)驗(yàn)通過(guò)關(guān)閉、開(kāi)啟chrome訪問(wèn)socket的權(quán)限來(lái)驗(yàn)證ACL權(quán)限機(jī)制在Android權(quán)限管控中的有效性。設(shè)置設(shè)備文件/dev/socket/dnsproxyd中chrome的ACL訪問(wèn)權(quán)限為“”，關(guān)閉權(quán)限后打開(kāi)chrome，發(fā)現(xiàn)網(wǎng)頁(yè)顯示“net：：ERR NAME NOT RESOLVED”的消息，同時(shí)查看日志，在日志中發(fā)現(xiàn)“permission denied.”的記錄。

對(duì)于攝像頭設(shè)備文件，設(shè)置UID為10023的美圖秀秀訪問(wèn)/dev/video3的權(quán)限為“”， /dev/video3文件路徑為前置攝像頭設(shè)備文件句柄。打開(kāi)美圖秀秀使用前置攝像頭進(jìn)行攝像時(shí)，前置攝像頭啟動(dòng)失敗，查看日志文件記錄，其中“mm camera open： cannot open control fd of ′/dev/video3′ （Permission denied） ”的記錄表明前置攝像頭設(shè)備文件打開(kāi)失敗。

為了檢驗(yàn)本系統(tǒng)動(dòng)態(tài)管控已root應(yīng)用程序訪問(wèn)系統(tǒng)資源的有效性，本實(shí)驗(yàn)對(duì)RE應(yīng)用程序進(jìn)行root。RE應(yīng)用程序userId為10053，打開(kāi)應(yīng)用程序，進(jìn)入/data目錄后界面列出了該目錄下所有的文件。再設(shè)置其對(duì)該目錄的訪問(wèn)權(quán)限為x，限制應(yīng)用程序訪問(wèn)data目錄，再次進(jìn)入data文件夾后顯示需要root，同時(shí)沒(méi)有列出該目錄相應(yīng)的文件。

同樣地，通過(guò)對(duì)其他系統(tǒng)資源的驗(yàn)證，表明ACL訪問(wèn)控制機(jī)制能夠?qū)?yīng)用程序訪問(wèn)系統(tǒng)資源起到訪問(wèn)控制的作用，本文實(shí)現(xiàn)的權(quán)限管控系統(tǒng)具有一定的有效性。

3.4?應(yīng)用安全性測(cè)試

ACL權(quán)限管控機(jī)制將每個(gè)操作授權(quán)給特定的 User 用戶或者 Role 角色，只允許這些用戶或角色對(duì)一個(gè)對(duì)象執(zhí)行這些操作。在沒(méi)有顯式指定的情況下，system server中的每一個(gè)對(duì)象都會(huì)有一個(gè)默認(rèn)的 ACL 值。這個(gè)值代表了所有的用戶對(duì)這個(gè)對(duì)象都是可讀可寫的。一個(gè) User 必須擁有讀權(quán)限才可以獲取一個(gè)對(duì)象的數(shù)據(jù)，同時(shí)，一個(gè) User 需要寫權(quán)限才可以更改或者刪除一個(gè)對(duì)象。ACL實(shí)現(xiàn)數(shù)據(jù)級(jí)的訪問(wèn)更靈活，能夠提高應(yīng)用系統(tǒng)的安全策略，對(duì)系統(tǒng)的變化有更大的伸縮性。下面代碼對(duì)支持ACL應(yīng)用的安全性進(jìn)行了測(cè)試。

不使用ACL代碼：

程序前

AVObject *post=[AVObject objectWithClassName：@"Post"];

[post setObject：@"Hello" forKey：@"title"];

[post setObject：@"Hello wold！" forKey：@"content"];

[post saveInBackground];

程序后

由于ACL有默認(rèn)值可讀可寫，模擬請(qǐng)求后返回請(qǐng)求結(jié)果。

程序前

{

"updatedAt"："2019-07-20T09：52：14.137Z"，

"objectId"："58705a24128fe1006b275274"}

程序后

請(qǐng)求成功，數(shù)據(jù)已被修改。因?yàn)樗?ACL 值是允許所有人可寫可讀，所以請(qǐng)求被接受。

使用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];

程序后

模擬請(qǐng)求后請(qǐng)求結(jié)果，請(qǐng)求失敗。

程序前

{

"code"：1，

"error"："Forbidden writing by objects ACL."

}

程序后

由于 ACL 的值顯示該條 Post 只允許一個(gè)特定的用戶修改，所以請(qǐng)求被拒絕。實(shí)驗(yàn)結(jié)果表明支持ACL的應(yīng)用安全性更高。

4?結(jié)語(yǔ)

針對(duì)Android權(quán)限管控不足帶來(lái)的問(wèn)題，本文提出了基于ACL訪問(wèn)控制機(jī)制的細(xì)粒度權(quán)限管控方案。該方案在原有UGO訪問(wèn)控制的基礎(chǔ)上，引入了Linux中的ACL訪問(wèn)控制機(jī)制，在原有UGO權(quán)限檢查之后，增加了ACL的權(quán)限檢查，ACL訪問(wèn)控制機(jī)制能根據(jù)應(yīng)用程序的UID提供了更加細(xì)粒度的權(quán)限管控。用戶可以動(dòng)態(tài)地設(shè)置指定系統(tǒng)資源和應(yīng)用程序的ACL權(quán)限信息，實(shí)現(xiàn)權(quán)限細(xì)粒度管控的功能，從而對(duì)系統(tǒng)重要資源和數(shù)據(jù)起到保護(hù)作用，阻止一些使用本地代碼的以及獲取root權(quán)限的應(yīng)用程序的惡意訪問(wèn)。

本文在實(shí)現(xiàn)完整權(quán)限管控系統(tǒng)后，對(duì)原型系統(tǒng)進(jìn)行了大量的評(píng)估，包括系統(tǒng)對(duì)應(yīng)用程序的兼容性、訪問(wèn)權(quán)限管控有效性、支持ACL應(yīng)用的安全性。測(cè)試的結(jié)果顯示ACL能使數(shù)據(jù)級(jí)的訪問(wèn)更靈活，能夠改善應(yīng)用系統(tǒng)的安全策略，對(duì)系統(tǒng)資源起到一定的保護(hù)作用。

參考文獻(xiàn) （References）

[1]?ACL. ACL（5）Linux man page [EB/OL]. [2019-03-23].http：//linux.die.net/man/5/acl.

[2]?尼見(jiàn). 安卓平臺(tái)下面向隱私保護(hù)的惡意程序分析與檢測(cè)方法研究[D]. 北京： 北京工業(yè)大學(xué)， 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]?孫亞楠，石文昌，梁洪亮，等. 安全操作系統(tǒng)基于ACL的自主訪問(wèn)控制機(jī)制的設(shè)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)科學(xué)， 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環(huán)境下訪問(wèn)控制列表機(jī)制的設(shè)計(jì)與實(shí)現(xiàn)[J]. 解放軍理工大學(xué)學(xué)報(bào)（自然科學(xué)版）， 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.