基于訪問控制列表機制的Android權限管控方案

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

摘 要：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.