曹震寰 蔡小孩 顧夢鶴 顧小卓 李曉偉

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

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

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

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

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

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

本文基于ACL訪問控制機(jī)制的權(quán)限管控系統(tǒng)進(jìn)行了全面的測試，包括系統(tǒng)的兼容性測試、有效性測試和高版本兼容性測試。結(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)行時權(quán)限， 運(yùn)行時權(quán)限授予從安裝權(quán)限演進(jìn)而來，對于正常的權(quán)限，安裝時須在AndroidManifest.xml中顯式聲明。對于危險權(quán)限，不但需要在AndroidManifest.xml中聲明，而且還需要用戶明確授予，如果設(shè)備運(yùn)行的是Android 6.0或更高版本，并且應(yīng)用的targetSdkVersion是23或更高版本，則應(yīng)用在運(yùn)行時向用戶請求權(quán)限。如果設(shè)備運(yùn)行的是Andorid 5.1（API級別22）或更低版本，并且應(yīng)用的targetSdkVersion是22或更低版本，應(yīng)用程序安裝時，系統(tǒng)會將AndroidManifest.xml文件中的permission信息保存在package.xml文件中。程序啟動后，就會將package.xml中的權(quán)限信息讀取至內(nèi)存中，在APP（Application）進(jìn)行資源訪問時，系統(tǒng)服務(wù)調(diào)用System Server提供的PermCheck函數(shù)對比資源要求的permission許可和內(nèi)存中的許可，進(jìn)行訪問控制決策。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.2?ACL服務(wù)模塊

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

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

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

上述三個模塊構(gòu)成了基于ACL訪問控制機(jī)制的權(quán)限訪問系統(tǒng)的主要架構(gòu)。首先，用戶在權(quán)限管控中心應(yīng)用程序中執(zhí)行設(shè)置應(yīng)用程序訪問權(quán)限的操作，該操作調(diào)用ACLService系統(tǒng)服務(wù)中相關(guān)API。系統(tǒng)服務(wù)中的API通過封裝后將資源、權(quán)限、應(yīng)用程序UID等參數(shù)傳遞給system_server，最后system_server通過socket與zygote進(jìn)行交互。zygote作為服務(wù)端接收到來自system_server的消息后，執(zhí)行權(quán)限設(shè)置的操作并將執(zhí)行結(jié)果返回到system_server中。ACL訪問控制機(jī)制支持模塊將zygote執(zhí)行的操作落實(shí)到權(quán)限管控中。先被使用的ACL動態(tài)庫會調(diào)用Android系統(tǒng)庫bionic中與擴(kuò)展屬性相關(guān)的函數(shù)，再通過系統(tǒng)調(diào)用執(zhí)行內(nèi)核層中的操作，將ACL權(quán)限信息與文件擴(kuò)展屬性聯(lián)系在一起。給資源設(shè)置具體的訪問權(quán)限之后，每當(dāng)有應(yīng)用程序要訪問相應(yīng)的資源時，系統(tǒng)會對通過UGO權(quán)限檢查的訪問進(jìn)行ACL權(quán)限檢查，當(dā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屬性中的訪問限制。ACL是物理文件系統(tǒng)的一個屬性，存儲在文件系統(tǒng)中，在系統(tǒng)啟動后再從外存讀取和寫入到內(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ù)修改過的配置文件生成新的booting.img，在系統(tǒng)啟動后，用新的內(nèi)核替代已編譯的內(nèi)核。在替換之后，ACL在Android的EXT4文件系統(tǒng)中將會成為文件擴(kuò)展屬性中的一個屬性，存儲在inode的xattr_entry中，每個文件或者目錄都有一個inode用于記錄它們的一些信息，例如創(chuàng)建時間、文件類型、訪問權(quán)限等信息。

2.4?Android中ACL動態(tài)庫的編譯

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

首先，從公開社區(qū)下載Linux中運(yùn)行的‘libacl的動態(tài)庫源碼，由于Linux和Android編譯器的不同，需要重構(gòu)部分‘libacl動態(tài)庫源碼來保證順利編譯?！甽ibacl的源碼整合在MYAOSP/system/core/目錄下。源碼中總共包含了256個文件，但是大部分并非必要的功能，例如：man指令、chacl指令等，移除這些非必要的功能后，‘libacl的源碼目錄包含7個頭文件，46個C文件以及一個makefile文件，makefile文件定義了一系列的規(guī)則來指定文件的編譯規(guī)則。過多的C文件和頭文件混雜在一起導(dǎo)致改寫makefile文件過于復(fù)雜，因此，本次工作將‘libacl目錄中的源碼分成頭文件和C文件兩個目錄，頭文件再引用ACL相關(guān)源碼中用到的所有頭文件。根據(jù)每個C文件實(shí)現(xiàn)的功能，將其劃分成三種類別，如表2所示，將源碼分別整合至這3個文件中，其中：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動態(tài)庫中導(dǎo)出的相關(guān)函數(shù)，包括檢查ACL信息是否有效等。

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

ACL動態(tài)庫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通信，在已有的通信開銷的基礎(chǔ)上進(jìn)行請求響應(yīng)盡可能減少了對系統(tǒng)的影響并可以省去創(chuàng)建新連接的開銷。

圖2詳細(xì)描述了整個ACL服務(wù)模塊的實(shí)現(xiàn)。首先，在system server中注冊一個新的系統(tǒng)服務(wù)ACLService，為權(quán)限管控中心提供ACL權(quán)限相關(guān)的接口。zygote和system server通過socket進(jìn)行通信，zygote創(chuàng)建注冊socket后，會對socket進(jìn)行監(jiān)聽，檢查是否有請求進(jìn)入。zygote調(diào)用runSelectLoop（）方法對來自system server中ActivityManagerService的請求進(jìn)行監(jiān)聽（zygote和system server之間的通信專門用于創(chuàng)建進(jìn)程請求的響應(yīng)），該方法通過循環(huán)的方式檢查請求，一旦有來自system server的請求，zygote就會創(chuàng)建一個新的對象ZygoteConnection放入等待請求處理的隊(duì)列中。最后通過調(diào)用一個函數(shù)runOnce（）進(jìn)行請求的響應(yīng)。在該函數(shù)中，首先要對請求進(jìn)行判斷，通過分析傳入的參數(shù)，判斷該請求為創(chuàng)建進(jìn)程的請求，然后調(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ù)中注入了一個分支，為了便于判斷ACL權(quán)限相關(guān)的請求，本方案在參數(shù)列表parsedArgs中增加了一個新的參數(shù)execShell，當(dāng)execShell為true時，就執(zhí)行runOnce（）函數(shù)的封裝函數(shù)ExecuteAclCmd（）。因此，當(dāng)一個請求來自system server時，可以通過execShell參數(shù)來判斷該請求是用于創(chuàng)建新進(jìn)程還是用于執(zhí)行ACL權(quán)限相關(guān)的操作。在函數(shù)ExecuteAclCmd中調(diào)用2.4節(jié)編譯的libacl.so動態(tài)庫中相關(guān)的函數(shù)，再將結(jié)果返回給system server。最后，在Process進(jìn)程中注入handleAcl（）函數(shù)作為客戶端發(fā)起權(quán)限操作請求的入口。后續(xù)對請求參數(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ī)制中的安全策略通過主體和客體的安全上下文定義主體是否有權(quán)限訪問客體。通常，一個策略中包含主體（域）、客體（類型）、操作權(quán)限，其中操作權(quán)限描述了主體能對客體進(jìn)行的操作，如讀、寫、設(shè)置文件屬性等。

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

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

前面章節(jié)描述了整個系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)的要點(diǎn)，本章將對上述的原型系統(tǒng)進(jìn)行實(shí)驗(yàn)分析。為了全面準(zhǔn)確地評估該系統(tǒng)，本文從三方面進(jìn)行評估，分別是應(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作為測試版本。在Nexus 6中部署LineageOS Android 8.1.0測試，同樣的，原系統(tǒng)也使用部署了Android 5.1.1 r14 tag和LineageOS Android 8.1.0與Nexus 6兩個測試版本作對比。

3.2?APP兼容性測試

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

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

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

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

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

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

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

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

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

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

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

不使用ACL代碼：

程序前

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

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

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

[post saveInBackground];

程序后

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

程序前

{

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

"objectId"："58705a24128fe1006b275274"}

程序后

請求成功，數(shù)據(jù)已被修改。因?yàn)樗?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];

程序后

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

程序前

{

"code"：1，

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

}

程序后

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

4?結(jié)語

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

本文在實(shí)現(xiàn)完整權(quán)限管控系統(tǒng)后，對原型系統(tǒng)進(jìn)行了大量的評估，包括系統(tǒng)對應(yīng)用程序的兼容性、訪問權(quán)限管控有效性、支持ACL應(yīng)用的安全性。測試的結(jié)果顯示ACL能使數(shù)據(jù)級的訪問更靈活，能夠改善應(yīng)用系統(tǒng)的安全策略，對系統(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]?尼見. 安卓平臺下面向隱私保護(hù)的惡意程序分析與檢測方法研究[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的自主訪問控制機(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)境下訪問控制列表機(jī)制的設(shè)計(jì)與實(shí)現(xiàn)[J]. 解放軍理工大學(xué)學(xué)報（自然科學(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.