Android應用程序權限自動裁剪系統*

白小龍

(清華大學計算機系，北京 100084)

Android應用程序權限自動裁剪系統*

白小龍

(清華大學計算機系，北京 100084)

Android系統使用權限機制對應用程序進行控制，即應用程序需要使用哪些系統資源就必須提前聲明相應的權限。為了確保安全性和可靠性，應用程序聲明權限時應該滿足最小特權原則，即只聲明其所需要使用到的最少權限，但現實中有很多應用存在權限過度聲明的現象，給用戶帶來安全隱患。提出了一種Android應用程序權限自動裁剪系統PTailor，通過對Android應用程序安裝文件(APK文件)進行分析和修改，使其滿足最小特權原則。PTailor首先從APK文件中提取程序所調用的所有系統API，并在預先生成的API權限映射表中查找該API所對應的系統權限，從而得到應用程序實際使用到的最少權限列表。然后根據該權限列表對程序的權限聲明文件進行修改，裁剪掉已聲明但未使用的權限。最后將裁剪過的權限聲明文件與程序的其他部分重新合并成新的APK文件，新的APK文件中除了所聲明權限滿足最小特權原則外，其結構和語義都沒有發生改變。使用PTailor對現實中的1 246個Android應用進行權限裁剪實驗，實驗結果表明，PTailor能夠在很短的時間內完成權限分析和裁剪，而且大多數被裁剪的程序都能夠正確運行。

Android應用程序；最小特權原則；權限過度聲明；權限自動裁剪

1 引言

近年來，隨著智能手機的普及率不斷提高，手機安全問題越來越引起人們的重視。越來越多的手機應用程序給用戶帶來便利的同時，也存儲著越來越多的用戶隱私數據，因此，手機應用程序的安全性和可靠性尤為重要。

智能手機中，Android手機占有了巨大的市場份額。根據市場調研機構Strategy Analytics的最新研究報告[1]，2013年Android手機占全球智能手機市場份額高達79%，增幅達62%。但是，由于系統開源性和應用市場開放性，Android平臺極易遭到攻擊。而且由于Android應用程序的編寫沒有明確的規范，這使得Android應用程序的安全性和可靠性良莠不齊。

Android系統使用一種權限機制來對應用程序進行訪問控制，應用程序想要通過系統提供的API進行某種操作或使用某種資源，就必須具有與該API相對應的權限。這些權限必須聲明在程序的AndroidManifest.xml文件中，該文件作為應用的重要組成部分在應用被安裝時由系統進行檢查并提醒用戶該應用具體聲明了哪些權限。應用程序在進行操作或使用資源時，Android系統會檢查其是否已聲明過相應的權限。例如，從圖1的代碼段中可以看出，應用程序需要使用TelephonyManager的getDeviceId()函數來獲取設備編號，并使用SmsManager的sendTextMessage()函數來發送短信，則該應用程序必須在其AndroidManifest.xml文件中聲明READ_PHONE_STATE和SEND_SMS權限(如圖2所示)，而系統會在該應用被安裝時提醒用戶該應用將讀取手機狀態和ID并發送短信(如圖3所示)。

1. TelephonyManagertm=(TelephonyManager)getSystemService(TELEPHONY_SERVICE);2. StringdeviceId=tm.getDeviceId();3. SmsManagersmsManager=SmsManager.getDefault();4. smsManager.sendTextMessage("10010",null,deviceId,null,null);

Figure 1 Code snippet of using system resource圖1 應用程序使用系統資源代碼段

Figure 2 Xml segment of permission declaration

圖2 應用程序權限聲明xml文檔段

Figure 3 Screenshot of permission notification while installation圖3 應用程序安裝權限提醒截圖

開發者在編寫Android應用程序時應該遵循最小特權原則，即進行哪些操作或者使用哪些資源，就只聲明與這些操作和資源相關的權限，而不應該聲明過多不使用的權限。但是，很多開發者并沒有遵循這一原則，造成了權限過度聲明，文獻[2]分析了940個Android應用，發現有323個聲明了不使用的過多權限。過度聲明的權限不僅會給用戶帶來誤解，使用戶對程序的可靠性和個人隱私的保密性產生懷疑，而且會帶來安全隱患。當權限過度聲明的應用程序存在bug時，這些程序可能會被其他惡意程序利用，從而對用戶隱私或手機安全造成威脅。導致Android應用程序權限過度聲明的主要原因有以下幾點：

(1)Android文檔不完善。Android文檔未給出每個API所需的權限，有些文檔給出的API權限信息甚至是錯誤的。文獻[2]對Android 2.2進行分析發現，一共有1 259個API需要使用權限，但是，Android文檔只描述了其中的78個，其中有6個API所描述的權限與其實際所使用到的權限不符。

(2)權限名稱很接近，容易混淆。例如ACCESS_NETWORK_STATE和ACCESS_WIFI_STATE，從名稱看兩者都是訪問網絡的狀態，但實際上兩者被用于不同的API中，程序員由于不清楚兩者的具體含義，很容易同時聲明這兩個權限。

(3)Android允許應用程序請求其他應用程序進行某些操作，這些被請求的應用需要具有相關的權限，但進行請求的應用并不需要這一權限。例如，應用可以請求瀏覽器打開某一個URL，這時該應用并不需要INTERNET權限，因為訪問網絡的行為并不是由該應用完成的。有些開發者并不了解這點，導致了聲明不必要的權限。

雖然有很多研究工作分析了應用程序權限過度聲明現象，但還沒有研究提出如何自動地處理和控制過度聲明的權限。針對權限過度聲明這一問題，本文提出了一種Android應用程序權限自動裁剪系統，稱為PTailor(Permission Tailor)。PTailor系統通過檢查Android應用程序安裝文件(APK文件)，提取程序中所有API調用，分析這些API所需的對應權限，獲得程序所使用的最少權限列表，并通過該列表對應用程序所聲明的權限列表進行裁剪，刪除掉那些已聲明但未使用的權限，從而使程序滿足最小特權原則。且要求系統的裁剪處理過程能夠在很短的時間內完成，并不會對大多數程序的正確運行產生影響，使其能夠適用于對大量程序進行自動分析和裁剪，提高程序安全性和可靠性。

本文的主要貢獻和創新點如下：

(1)提出了一種Android應用程序權限自動裁剪系統PTailor，PTailor通過對Android應用程序文件進行分析和修改使其滿足最小特權原則。并通過實驗對PTailor的權限裁剪性能、裁剪后可用性進行了評測。

(2)通過實驗結果，對Android應用程序權限過度聲明現象和發展趨勢進行了分析，并對以往關于API權限分析工作的完整性進行了分析。

本文的具體內容組織如下：第2節介紹國內外與Android權限相關的研究現狀；第3節將對Android權限等背景知識進行介紹；第4節重點介紹PTailor系統的組成模塊，并對各模塊的具體功能和算法進行詳細的闡述；第5節闡述了實驗設計以及結果分析，從多方面對PTailor系統進行了評測；第6節對PTailor設計和實驗中的一些問題進行討論，并對未來的工作進行展望；第7節對全文進行總結。

2 相關工作

Android系統采用權限機制對應用程序進行管理和控制，應用在安裝時必須聲明與其所使用到的資源相關的權限，且只能使用所聲明過的權限范圍內的資源。這一機制簡單但控制能力有限，而且安裝時聲明權限的方式無論對于開發者還是用戶都具有一定的局限性。國內外有很多學者針對這一權限管理機制的使用現狀進行分析或者提出更加有效的管理方式。

2.1 API權限映射分析相關工作

由于Android文檔對于大多數API所需權限沒有明確的解釋，導致了很多權限過度聲明現象的發生。因此，研究API與其所需權限的映射，并分析現有應用程序中權限過度聲明情況很有必要。

Felt A P等人[2]通過單元測試的方式分析了Android 2.2.1中的API權限映射關系，發現了1 259個API在使用時需要聲明權限，但是，Android 2.2的文檔中只給出了78個API的權限使用說明。同時，他們提出了Stowaway工具，用于檢查應用程序的權限過度聲明情況。并使用Stowaway對940個Android應用進行了分析，發現約三分之一(323)的應用存在權限聲明但未使用的情況，并分析出產生這種現象的主要原因是Android文檔的不完整。在此項研究基礎上，Felt A P等人還對權限系統的設計提出了一些指導意見[3]。

Au K W Y等人[4]提出PScout系統,通過對Android系統權限檢查部分源碼進行靜態分析的方式分析了API與其權限的映射關系，并分析了四個版本的Android系統中API與其權限的對應情況，包括隱藏的系統API和顯式的通用API。同時，他們還通過模糊測試的方式對1 260個應用程序進行了權限聲明檢查，發現543個應用聲明了額外未使用的權限。

相似地，Bartel A等人[5]提出了COPES系統,使用基于call graph的靜態分析從Android 系統框架中提取出函數調用與所需權限的對應關系。對Android 2.2進行分析，發現共有9 562個函數需要聲明權限。但是，不同于PScout的是，該工作只分析了API函數調用中的權限，沒有考慮到Intent和Content Provider等其他情況下所需的權限。

Vidas T等人[6]從Android文檔中提取API權限映射，但由于Android文檔的API權限信息非常不完善，所以該研究工作所獲得的權限規范也不完整。

Wei X等人[7]使用Stowaway工具對237個應用的1 703個版本的權限聲明演化過程進行了分析，發現19.6%在新版本中存在權限過度聲明現象，25.2%在原本的版本中就已經過度聲明?？傮w上呈現出權限過度聲明的應用程序逐漸增多的趨勢。

Yang Bo等人[8]提出了一種基于數據流分析的靜態檢測工具Brox，用于檢測Android應用程序是否聲明了過多的權限。

這些研究工作雖然都對Android系統中API與其權限的映射關系進行了分析，或分析了應用程序的權限過度聲明情況，但是都沒有運用這一映射關系對應用程序的權限過度聲明進行控制，也沒有對過度聲明的權限進行裁剪，無法確認API權限映射以及應用程序權限過度聲明分析結果的有效性。

2.2 Android權限其他相關研究

2.2.1 應用程序的權限特征分析

分析不同程序的權限特征可以幫助人們發現程序的潛在安全威脅。Enck W等人[9]提出了Kirin系統,從應用程序中提取具有潛在安全威脅的權限組合，用于向用戶提供安全建議。Barrera D等人[10]對1 100個Android應用程序進行分類分析，使用自組織映像網絡算法對不同功能類別應用程序所聲明權限的特征進行分析。Peng H等人[11]根據應用程序的權限組合使用概率生成模型對程序的危險指數進行評分。Pearce P等人[12]分析了應用程序中廣告所需的額外權限，并提出AdDroid架構用于將廣告與應用程序主體分離，使得應用程序不需要為其廣告額外聲明權限。Zhang Y等人[13]提出了VetDroid系統用于刻畫程序的權限使用行為特征，從而更好地幫助安全分析師分析程序的內部敏感行為。Yang Huan等人[14]使用包括權限信息在內的多種特征對Android應用程序的惡意行為進行檢測。Zhang Rui等人[15]基于Android應用程序權限的相關性特征對Android惡意軟件進行聚類分析。

2.2.2 權限使用控制或提醒相關研究

讓用戶了解或控制程序正在使用的權限對于保護用戶隱私很有幫助。Nauman M等人[16]提出了Apex架構以及Bao Ke-jin等人[17]提出的權限管理模型，可以使用戶選擇將哪些權限賦予應用程序，從而起到自主訪問控制的作用。Xu R等人[18]提出的Aurasium系統可以在不修改Android源碼或獲得Root權限的情況下對應用程序的API使用請求進行用戶提醒和訪問控制。Livshits B等人[19]在Windows Phone上添加了系統資源訪問提醒，使得當應用程序訪問某些系統資源時用戶會得到相應的提醒，從而選擇允許或拒絕該訪問。

2.2.3 應用程序訪問控制相關研究

Android基于權限機制的訪問控制方式雖然簡單但是控制能力有限，很多學者致力于尋找更加有效的訪問控制方式。由于Android系統是基于Linux操作系統的中間層系統，Smalley S等人[20]基于Linux原有的一種強制訪問控制機制——安全強化Linux(SELinux)提出SEAndroid，用于在Linux內核以及Android中間層框架上實現強制訪問控制MAC(Mandatory Access Control)。該技術現已被Android主流版本所吸納。Bugiel S等人[21]提出FlaskDroid系統，借助于開發者所定義的策略語言，實現靈活而細粒度的強制訪問控制。Bugiel S等人[22]還提出過基于TOMOYO Linux強制訪問機制實現對Android應用進行強制訪問控制的TrustDroid。Ongtang M等人[23]提出的Saint系統可以根據策略對應用程序安裝時的權限授予和運行時的權限使用進行控制。Tang Wei[24]提出了基于安全距離的權限機制擴展方案，并提出了基于上下文的運行時檢測方案。

3 背景介紹

3.1 Android權限機制

Android對系統 API進行權限檢查主要有三種情況：函數調用、Intent和Content Provider。

函數調用就是直接調用系統API函數從而使用某些資源，例如使用SmsManager類中的sendTextMessage()函數來發送短信。

Intent是Android系統中進程間通信的主要方式，即一個程序如果需要另一個程序完成某個工作，就需要向該程序發送一個具有特定Action參數的Intent。而請求一些系統程序時則需要具有相應的權限才能發出Intent。例如，應用請求使用撥號程序撥打電話，需要向撥號程序發送具有android.intent.action.CALL參數的Intent，則該應用需要聲明android.permission.CALL_PHONE權限。

Content Provider存儲著一些數據信息，并向其他程序開放用于獲取相關的數據。應用程序如果需要獲取Content Provider中的數據，則需要通過不同的URL schema進行請求，對于系統提供的某些Content Provider，應用程序進行請求時必須具有相應的權限。例如，當應用程序使用schema為content://sms的URL請求讀取設備中的短信列表時就需要具有android.permission.READ_SMS權限。

3.2 APK文件

Android應用程序使用Java語言編寫并編譯成一種特殊的字節碼文件，稱為Dalvik Bytecode，所有Java Class的Dalvik Bytecode合并在一起組成一個dex文件。除了dex文件，應用還需要在一個AndroidManifest.xml文件中聲明應用程序的組成部分以及所使用到的權限。這個AndroidManifest.xml文件與dex文件以及其他一些所需要使用到的資源文件通過JDK(Java Development Kit)中的jar工具打包并通過jarsigner工具使用開發者私鑰進行簽名，從而形成了Android應用程序包文件(簡稱APK文件)，APK文件即為應用程序的安裝文件。

4 PTailor系統

本文提出了一種Android應用程序權限自動裁剪的系統PTailor，PTailor主要采用靜態分析技術，對Android APK文件進行分析和修改。PTailor由五個部分組成，包括API權限映射表生成模塊、APK分解模塊、API提取模塊、manifest裁剪模塊和APK合并模塊。PTailor系統架構如圖4所示，對APK文件的分析和修改的流程如圖5所示。

Figure 4 Architecture of PTailor圖4 PTailor系統架構圖

Figure 5 Workflow of PTailor圖5 PTailor對APK文件分析和修改流程圖

4.1 API權限映射表生成模塊

API權限映射表生成模塊負責讀取API權限映射數據文件，生成API與其權限的映射表，屬于系統的準備工作。不同于其他模塊對每個APK文件都要運行一次，該模塊對所有需要處理的APK文件只需要運行一次即可。

4.1.1 API權限映射數據源

本文中，我們使用PScout[4]中得到的Android 4.1.1 API權限對應結果數據作為API權限映射數據源。對應于Android權限檢查機制的三種情況，這一數據源包括API函數調用與其所需權限對應數據、Intent Action與其所需權限對應數據、Content Provider URL schema與其所需權限對應數據。PTailor同樣可以使用其他數據作為其API權限映射源，也可以由用戶自定義API權限的映射關系，但PScout的API權限映射關系是現階段最為完整的，故本文目前采用該數據。

4.1.2 API權限映射表數據結構

PTailor使用散列表的數據結構存儲API與其權限的映射關系，由于有些API會對應多個權限，所以需要使用單個key對應多個value的Multimap數據結構，以API為key，以其所需權限為value。這個API與權限的映射表APM(API Permission Map)用于在API提取模塊中獲得所提取的API所對應的權限。

4.2 APK分解模塊

APK分解模塊的主要工作是對Android應用程序APK文件進行解壓縮，從而獲得dex文件和AndroidManifest.xml文件。這兩個文件分別用于API提取模塊和manifest裁剪模塊當中。API提取模塊通過遍歷dex文件來檢查所有API調用。manifest裁剪模塊通過API提取模塊中所得到的實際使用的權限列表對AndroidManifest.xml文件所聲明的權限進行修改，裁剪掉那些已聲明但未使用的權限。經過裁剪的AndroidManifest.xml文件與原始的dex文件最后一起通過APK合成模塊合成新的無權限過度聲明的APK文件。

4.3 API提取模塊

API提取模塊是PTailor的核心組成部分。其主要作用是從dex文件中提取所有使用到的權限。在3.1節中已經介紹過，由于Android對API的權限檢查包括函數調用、Intent和Content Provider三種情況，所以PTailor的API提取模塊需要對這三種情況中所使用到的權限進行分別提取。相對應地，API提取模塊共分為三個子模塊，即函數調用提取模塊、Intent提取模塊和Content Provider提取模塊。這三個子模塊都以APK分解模塊中得到的dex文件和API權限映射表生成模塊中產生的API權限映射表APM作為輸入，輸出為應用程序實際使用到的最小權限列表。

4.3.1 API函數調用提取模塊

API函數調用提取模塊的主要工作是提取程序中的所有函數調用，并在API權限映射表中查找所調用函數對應的權限，將查找到的權限添加到輸出的已使用權限列表中。具體算法如算法1所示。

算法1API函數調用權限提取算法

輸入：Dalvik bytecode文件F，API權限映射表APM;

輸出：已使用的權限列表L。

1. FOR each ClassCinFDO

2. FOR each MethodMinCDO

3. FOR each InstructionIinMDO

4.θ← GetOpcode (I)

5. IFθ= invoke THEN

6.λ← GetInvokedMethodWithClass (I)

7. IFλis inAPMTHEN

8.P← GetPermissionsByAPI (APM,λ)

9. FOR each PermissionpinPDO

10. AddToList (L,p)

11. END

12. ELSE

13.α← GetDeclaringClassName(λ)

14.β← GetMethodName (λ)

15. WHILEαis not NULL DO

16. IF (α:β) is inAPMTHEN

17.P←GetPermissionsByAPI(APM,λ)

18. FOR each PermissionpinPDO

19. AddToList (L,p)

20. END

21. BREAK

22. ELSE

23.α← GetSuperClass(α)

24. END

25. END

26. END

27. END

28. END

29. END

30. END

算法1的輸入為APK分解模塊中所獲得的dex文件F以及API權限映射表生成模塊中所獲得的API權限映射表APM，輸出為應用程序所使用到的權限列表L。Android應用程序是由多個Java Class組成的，而每個Class又是由多個Java Method組成的，每個Method中包含多個Dalvik指令(Instruction)，而只有invoke指令是函數調用指令，用于調用API函數。因此，算法1的第1～第3行中，API函數調用提取模塊遍歷每個Class的每個Method中的每個Instruction，并在第4、第5行檢查這個Instruction是不是invoke指令。如果是，則通過GetInvokedMethodWithClass()獲取invoke指令所調用的函數λ，λ中包括該函數的名稱、參數以及所屬類。算法在第7行判斷API權限映射表APM中是否有函數λ與其權限的映射，如果有，則在第8～第11行中，將APM中λ所對應的所有權限加入到輸出的已使用權限列表L中。為了保證L為最小權限列表，AddToList()對于同一個權限只會添加一次。

如果APM中沒有函數λ的權限映射，則算法會在第13～第24行檢查λ是否有可能繼承自APM中的某個API。例如，使用類X中的Z函數需要具有P權限，API權限映射表中包含(X:Z)→P的映射，但應用程序并沒有直接使用類X中的Z函數，而是通過類Y繼承類X，并調用Y中的Z函數。雖然Y并沒有對Z進行重寫，且調用類Y中的Z函數同樣需要P權限，但在APM中不包含(Y:Z)→P的映射。為了處理這種情況，算法在第13、第14行分別提取函數λ的所屬類α和函數名稱β，在第23行回溯類α的繼承關系鏈，并在第16行檢查APM中是否含有(α:β)的權限映射，如果沒有，則在第23行繼續回溯α，如果有，則在第17～第20行將APM中檢查到的權限列表加入到L中。API函數調用提取模塊回溯函數的繼承關系鏈的目的是防止由于某些應用通過繼承系統服務的方式訪問系統資源而導致的漏報。

4.3.2 Intent和Content Provider提取模塊

Intent提取模塊和Content Provider提取模塊分別用于提取應用程序通過Intent方式和Content Provider方式獲取系統資源時所需要的權限。

Intent提取模塊提取程序發出Intent請求時的Action參數，并在API權限映射表中查找這些Action參數所對應的權限，添加到已使用權限列表中。

Content Provider提取模塊提取程序發出的URL請求的schema，并在API權限映射表中查找這些schema所對應的權限，添加到已使用權限列表中。

Action參數和URL schema都是字符串類型，因此Intent和Content Provider提取模塊查找這兩個參數的方式是查找dex文件中是否有相應的字符串。

4.4 manifest裁剪模塊

經過API提取模塊獲得應用程序實際使用的權限列表之后，PTailor通過manifest裁剪模塊對聲明了權限的AndroidManifest.xml文件進行修改，裁剪掉已聲明但未使用的那些權限，從而達到最小特權原則。由于只修改manifest文件中權限聲明部分，且只刪除未使用過的權限聲明，所以PTailor的manifest裁剪模塊不會修改應用程序的結構。

4.5 APK合并模塊

APK合并模塊執行與APK分解模塊相反的操作。經過manifest裁剪模塊裁剪后的AndroidManifest.xml文件與APK分解模塊中所得到的dex文件以及分解出的其他一些資源文件一起經過APK合并模塊，重新合并成APK文件。重新合成的APK文件除了其manifest文件經過修改滿足最小特權原則以外，其他部分都沒有經過修改，因此不會影響應用程序原有的結構、功能和語義。APK合并模塊使用JDK中的jar命令對manifest文件、dex文件以及其他資源文件進行打包。Android要求每個應用程序的APK都需要經過開發者的私鑰簽名，這一簽名過程是不可逆的，即無法從APK文件中提取出原始開發者的私鑰信息。而APK分解模塊已經將原始APK文件中的簽名破壞了，在重新合成時無法用原始開發者的私鑰進行簽名。本文僅采用簡單隨機生成的私鑰使用JDK中的jarsigner工具對APK文件進行簽名，因為PTailor在實際使用中可以用于APK簽名并發布之前，幫助程序員確認其所開發的應用程序是否滿足最小特權原則。而且APK的簽名主要用于識別不同的開發者，重新合并時的簽名可以針對不同的開發者使用不同的隨機私鑰，并不影響簽名的作用。

5 實驗設計與結果分析

PTailor系統主要使用Java和Python語言實現，其中，除API提取模塊中的Intent和Content Provider子提取模塊和APK合并模塊是使用Python語言實現外，其余模塊都使用Java實現。其中API函數調用提取模塊使用到了開源項目dexlib2[25]對dex文件進行遍歷，manifest裁剪模塊使用開源項目axml[26]對二進制的AndroidManifest.xml文件進行修改。

本文通過實驗對以下幾個方面進行了評測和分析：PTailor系統的性能評測、裁剪后應用程序可用性評測、應用程序權限過度聲明分析、API權限映射數據源有效性分析。

5.1 實驗環境

實驗中，我們對現實中的Android應用程序APK文件使用PTailor進行權限分析和裁剪，并進行相應的評測。實驗數據集為Google Play[27]應用商店27個應用類別中銷量前50的免費應用，去除掉重復的應用，共1 246個APK文件。實驗主機內存為16 GB，CPU為8核Intel(R) Core(TM) i7-4770 CPU @ 3.40 GHz。PTailor系統的裁剪過程直接在實驗主機上完成。裁剪后應用程序可用性評測在實驗主機上的一個Android 4.1.1模擬器中完成。

5.2 性能評測

我們對所有1 246個APK文件分別使用PTailor進行權限分析和裁剪，并計算PTailor對每個APK文件進行分析和修改的整體時間，以及每個模塊所占用的時間，從而評測PTailor的性能。由于API權限映射表生成模塊是PTailor系統中的準備工作，不論APK文件數量多少，都只運行一次，所以在性能評測實驗中分析PTailor對APK文件的處理時間不考慮API權限映射表生成模塊的運行時間。

PTailor可以成功地對所有1 246個APK文件進行分析和裁剪，成功率為100%。所有APK文件的處理時間分布如圖6和圖7所示。圖6為處理時間分布柱狀圖，即橫坐標為m的數據柱值n表示有n個APK文件可以在m-1到ms內被PTailor處理完成。圖7為處理時間累積百分比折線圖，即橫坐標為m的數據點的縱坐標表示在ms內能完成PTailor處理的APK個數百分比。從圖6中可以看出，所有的1 246個APK文件都能夠在20 s內完成處理，而多數的APK文件的處理時間集中在2～7 s內。從圖7中可以看出，有91.6%的APK文件可以在10 s內完成處理。所以，PTailor可以在很短的時間內對Android應用程序進行權限分析和裁剪，適用于在Google Play這種大量應用程序集中的Android應用市場中對應用程序進行自動處理。

Figure 6 Processing time of PTailor圖6 APK文件總處理時間分布柱狀圖

Figure 7 Cumulative percentage line graph of processing time圖7 APK文件總處理時間累積百分比折線圖

除了對每個APK的整體處理時間進行統計，實驗還對每個APK在各個模塊中的處理時間進行了統計。除了API權限映射表生成模塊外，其他不同模塊的APK文件處理時間分布情況如表1～表4所示，其中不包括manifest裁剪模塊，因為很多應用程序不存在過度聲明的權限，所以不需要進行裁剪，且大多數需要裁剪的APK文件的裁剪時間都在1～2 ms之內，由于時間過短，所以不做統計。

Table 1 Processing time of APK decomposing module表1 APK分解模塊處理時間分布表

Table 2 Processing time of APIfunction call extracting module表2 API函數調用提取模塊處理時間分布表

Table 3 Processing time of Intent andcontent provider extracting module表3 Intent和Content Provider提取模塊時間分布表

Table 4 Processing time of APK composing module表4 APK合并模塊處理時間分布表

從表1和表2中我們可以看出，使用Java實現的APK分解模塊和API函數調用提取模塊的處理時間通常都在幾百毫秒之內，而使用Python實現的Intent和Content Provider提取模塊和APK合并模塊通常都需要幾秒的時間。造成這種時間差異的原因主要是使用Python實現的這幾個模塊都通過調用外部命令的方式進行分析和處理，例如find、grep、jar、jarsigner等等，并且這些命令都要頻繁進行文件的IO操作，調用外部命令和IO操作通常都需要花費較多時間。

5.3 可用性評測

可用性評測的目的是檢驗PTailor對APK的裁剪是否過度，經過裁剪的應用是否依然能夠正常運行。實驗采用Android SDK中的自動化壓力測試工具Monkey。

Monkey通過將隨機生成的UI事件序列注入到應用程序中的方式對應用程序進行壓力測試。在Monkey中可以設置事件序列中的事件個數，并可以指定只針對某一個應用進行測試。同時，可以通過設置隨機種子的方式，指定UI事件序列的順序。Monkey在程序運行結束后給出詳細的測試報告。如果應用程序在某一個UI事件后崩潰，Monkey將停止測試并自動退出，并報告該程序已經崩潰。另外Monkey還有可能因為無法找到應用程序的入口等原因而意外退出。使用Monkey進行壓力測試的目的是檢查PTailor的裁剪是否會影響程序的可用性。

實驗中，我們首先對所有未裁剪的APK文件進行Monkey測試，每個測試的隨機事件個數為2 000，并記錄下對每個APK進行測試時所使用的隨機種子seed。同時，我們還會記錄下未裁剪的應用中崩潰的應用以及導致Monkey測試失敗的應用，這些未裁剪就已經崩潰和意外退出的應用是由其本身錯誤或者與模擬器版本不兼容所導致的，對實驗沒有意義，所以在之后對裁剪過的APK文件進行Monkey測試時將不考慮這些已崩潰的應用。

然后，我們對裁剪過的APK文件進行Monkey測試。每個裁剪過的APK文件進行測試時所使用的隨機種子與其對應的未裁剪版本在進行測試時所記錄下的隨機種子seed相同，這使得裁剪前和裁剪后的同一個APK文件在進行Monkey測試時使用相同的UI事件序列。同樣地，我們也記錄下裁剪過的應用程序中崩潰的以及導致Monkey意外退出的程序。這些應用的崩潰可能是由于PTailor裁剪了過多權限所導致的，需要進行進一步分析。

在實驗過程中，對每一個APK文件的測試都單獨進行，每一次測試只安裝一個APK文件，對其進行Monkey測試結束后，將該APK文件卸載，從而避免對實驗環境的改變以及對其他應用測試的影響。但是，在安裝APK文件時，也會有一些APK文件安裝失敗，因此我們也會記錄安裝失敗的APK文件，并只對安裝成功的APK文件進行測試。整個實驗過程如圖8所示。

Figure 8 Workflow of usability experiment圖8 可用性測試實驗流程

在可用性測試結束后，對可用性測試結果進行統計和總結。在對未裁剪的APK文件進行Monkey測試時，共有73個APK文件安裝失敗，有202個APK文件崩潰或導致Monkey測試失敗。排除這些無意義的APK文件外，共有971個應用程序在未裁剪時能成功運行。對這971個應用程序的裁剪后版本進行Monkey測試，共有69個應用程序崩潰，而這69個應用程序中，有17個應用程序在PTailor分析結果中并沒有權限過度聲明現象，因此，這17個應用程序實際并沒有被裁剪，導致其崩潰的原因可能是網絡環境影響等因素，與PTailor權限裁剪無關。而剩余的52個崩潰的應用程序，只占全部1 246個應用程序的4.17%，占全部可運行的971個應用程序的5.35%，從而可以說明PTailor的權限裁剪只會影響很少的Android應用程序，大多數被裁剪的程序依然能夠正確運行。

5.4 應用程序權限過度聲明分析

使用PTailor對全部1 246個Android應用程序進行權限裁剪，我們發現一共有811個應用存在權限過度聲明的現象，占全部應用程序數量的65.1%。Felt A P等人[2]在2011年使用Stowaway對采集到的940個應用進行了分析，發現34.4%的應用存在權限過度聲明現象。Au K W Y等人[4]在2012年使用PScout對采集到的1 260個應用進行了分析，發現43.1%的應用存在權限過度聲明現象。將PTailor與這兩個工作相比較，從圖9中可以看出，從2011年到2014年，Android應用程序權限過度聲明現象呈現上升趨勢，這與文獻[5]中分析不同版本應用程序得出權限過度聲明程序數量隨時間不斷增加的結論基本一致。

Figure 9 Comparison of overprivileged applications圖9 權限過度聲明比例比較

在這811個權限過度聲明應用程序中，30.57%的應用只過度聲明了一個權限，49.25%的應用過度聲明權限個數小于或等于2個，74.88%的應用過度聲明權限個數小于或等于4個。具有不同過度聲明權限個數的應用程序數量分布柱狀圖如圖10所示。

Figure 10 Distribution of overprivileged permissions圖10 應用程序過度聲明權限個數分布柱狀圖

另外我們發現，在所有1 246個應用程序中，有很多應用聲明了名稱以android.permission.和com.android.為開頭但在Android系統中并不存在的權限。通常，名稱以android.permission.和com.android.為開頭的權限是Android的系統權限。這些以android.permission.和com.android.為開頭但在Android系統中并不存在的權限可能是某些Android應用程序自定義的權限，但是也有一些是根本不存在甚至是明顯書寫錯誤的權限。這些不存在或書寫錯誤的權限是由于程序開發者的個人因素所導致的，應該盡量避免。例如，

(1)與系統權限名稱相近，但根本不存在的權限。程序如果希望讀取短信，則需要聲明READ_SMS權限，但有些應用程序卻聲明了READ_MMS這個根本不存在的權限。

(2)無需聲明且根本不存在的權限。Android為每個應用程序提供獨立私有的內部存儲空間用于存儲數據，使用這個內部空間并不需要聲明任何權限，但有些應用程序卻聲明了READ_INTERNAL_STORAGE這個根本不存在的權限。

(3)書寫錯誤的權限。應用程序如果要錄制音頻，則需要聲明RECORD_AUDIO權限，但有些應用程序開發者卻將這一權限錯誤地書寫成了RECORDE_AUDIO。

5.5 API權限映射數據源有效性分析

4.1.1節中提到，PTailor現階段的API權限映射數據源來自于PScout[4]的實驗結果，據我們所知，PScout中所得到的API權限映射關系是目前最為完整的，其對Android 4.1.1的分析結果中包括了32 450個API函數直接調用權限映射，97個Intent Action權限映射和78個Content Provider URL schema權限映射，但經過實驗我們發現該數據源并不完善，存在很多缺陷。

5.5.1 權限覆蓋率分析

PScout對Android 4.1.1中的API權限映射進行分析，共找到了101個權限與API有所映射，但Android 4.1.1系統中的所有權限個數為180個。其中，Android系統中有92個權限在PScout中沒有得到對應，而在全部1 246個應用中有137個程序所聲明的權限包含在這92個PScout未對應的權限中。另外，PScout的API權限映射結果中，有13個權限是Android系統提供給系統級應用程序的特殊權限，無法被普通應用所使用。從以上結果中可以看出，PScout的權限覆蓋率僅為48.9%。

5.5.2 API映射分析

除了權限覆蓋不完整之外，PScout中的API權限映射關系也不完整。具體包括以下幾點：

(1)外部存儲設備訪問權限。如果應用程序想讀取或寫入SD卡中的文件，訪問sdcard目錄，則該應用必須具有READ_EXTERNAL_STORAGE或WRITE_EXTERNAL_STORAGE權限，同時為了對SD卡上的文件進行操作，有些應用程序還需要MOUNT_UNMOUNT_FILESYSTEMS權限。但是，PScout的API權限映射中沒有這些與SD卡文件操作相關的權限映射。

(2)WebView訪問網絡權限。Android系統提供WebView組件用于顯示Web頁面，任何使用WebView顯示Web頁面的應用程序都應該具有INTERNET權限。WebView可以在程序的代碼段中動態聲明，也可以在xml文件中靜態聲明。PScout的API權限映射結果中只包含WebView動態聲明API，而沒有xml靜態聲明WebView的權限映射。

(3)讀取Log權限。Android系統向應用提供用于記錄信息的Log接口，任何使用logcat命令讀取Log的應用程序都需要具有READ_LOGS權限，該權限信息在 PScout中沒有映射。

(4)漏報的API。PScout中雖然含有超過30 000個API與其權限的映射，但仍有一些需要權限的API沒有得到映射。例如，android.hardware.Camera中的open(int)函數需要CAMERA權限，但PScout中沒有該API的權限映射。

(5)不同參數對應的權限。對于有些API函數，當使用不同參數進行函數調用時，其所需的權限可能不同。例如，當應用程序打開一個具有TYPE_SYSTEM_ALERT參數的窗口，使窗口出現在所有其他窗口上時，程序應該具有SYSTEM_ALERT_WINDOW權限。但是，PScout沒有函數調用參數的權限映射信息。

6 討論

6.1 應用程序之間的請求

Android允許一個應用程序請求另一個應用程序進行某個操作、完成某項任務，這種請求只能通過消息傳遞的方式進行通知，而無法進行直接的函數調用。由于程序之間不能夠直接調用函數，而且程序之間也不存在請求傳遞的關系，如果被請求方將請求方的系統資源請求直接轉發出去，則請求方和被請求方都應該具有相應的權限。因此，并不存在某一個應用程序為其他應用程序預先申請權限、使得無權限一方調用有權限一方的情況，因此PTailor的裁剪不會影響程序之間的請求。

6.2 可用性評測方法局限性

5.3節中使用Monkey對PTailor裁剪后應用程序的可用性進行了評測。Monkey雖然可以通過隨機注入事件序列的方式對應用程序進行自動化的壓力測試，但這種方法具有一定的局限性。由于Monkey的事件類型和注入順序都是隨機的，所以使用Monkey測試并不能保證完全的代碼覆蓋率，可能導致測試的不完整，增加漏報率。但是，現階段還沒有代碼覆蓋率為100%的Android應用程序自動化測試方法，因此，本實驗的漏報率還無法測量。在未來的工作中，我們將設計并提出代碼覆蓋率更高、更符合程序流程結構的Android應用程序自動化測試方法。

6.3 導致裁剪后應用程序不可用的原因

從5.3節的可用性評測結果中可以看出，PTailor的權限裁剪依然會影響很少一部分Android應用程序的正常運行。導致這一結果的主要原因有以下幾點：

(1)API權限映射數據源的不完整性。PTailor可以使用任何API權限映射信息作為其數據源，本文中使用PScout[4]中得到的Android 4.1.1 API權限對應結果作為API權限映射數據源。據我們所知，該數據源中的API權限映射關系是目前最為完整的。但是，在5.5節中的API權限映射數據源有效性分析中可以看出該數據源的API權限映射關系并不完整，這可能導致PTailor將一些實際需要權限、但在數據源中沒有得到映射的API裁剪掉，從而導致過度裁剪，影響程序的正常運行。在未來的工作中，我們計劃研究并提出能夠發現更多API權限映射關系的方法，從而提高API權限映射數據源的完整性，減少PTailor的過度裁剪。

(2)Java反射機制的影響。Android應用程序使用Java語言編寫，Java提供反射機制允許應用程序在運行時動態地調用函數。PTailor的API函數調用提取模塊中沒有對反射機制的函數調用進行分析，完整的反射機制函數調用分析需要進行信息流敏感、跨函數的靜態分析。在未來的工作中，我們將在PTailor中增加對反射機制函數調用的靜態分析。

這些因素有可能引起PTailor由于無法找到某些權限在程序中所對應的API而導致的權限過度裁剪，但是不會導致應用程序過度聲明的權限沒有得到裁剪。即經過PTailor裁剪的應用程序權限集合，可能是其最小特權的子集，但不會是最小特權的超集。但是，由于現階段沒有完整的API權限映射數據，所以暫時無法證明經過PTailor裁剪的權限集合是否與應用程序的最小特權集合完全吻合。

7 結束語

Android應用程序的權限聲明應該滿足最小特權原則，但現實中的很多應用程序聲明了過多不使用的權限，從而可能帶來安全隱患。本文提出了一種Android應用程序權限自動裁剪系統PTailor，PTailor在應用程序中提取系統API調用信息，分析調用這些API所需的對應權限，得到應用程序實際所需要的最少權限，并將程序中多余的未被使用的權限裁剪掉，從而使得裁剪后的Android應用程序滿足最小特權原則。使用PTailor對現實中的1 246個Android應用程序進行權限分析和裁剪實驗，實驗結果表明91.6%的APK文件能夠在10秒內完成權限分析和裁剪，最長的處理時間為20秒，并且PTailor的裁剪不會對大多數程序的運行產生明顯影響。同時，文中還對應用程序權限過度聲明趨勢進行了分析，發現權限過度聲明的應用程序數量隨時間呈現上升趨勢，且應用程序存在因開發者個人因素所導致的錯誤權限聲明現象。另外，通過實驗我們還發現，以往的API權限映射分析研究工作還存在很多不足和缺陷。

[1] Android captured 79% share of global smartphone shipments in 2013 [EB/OL].[2014-05-16].http://blogs.strategyanalytics.com/WSS/post/2014/01/29/Android-Captured-79-Share-of-Global-Smartphone-Shipments-in-2013.aspx.

[2] Felt A P,Chin E,Hanna S,et al.Android permissions demystified[C]∥Proc of the 18th ACM Conference on Computer and Communications Security, 2011:627-638.

[3] Felt A P,Egelman S, Finifter M. et al. How to ask for permission[C]∥Proc of HotSec’12, 2012:1.

[4] Au K W Y,Zhou Y F,Huang Z,et al.Pscout:Analyzing the Android permission specification[C]∥Proc of the 2012 ACM Conference on Computer and Communications Security, 2012:217-228.

[5] Bartel A, Klein J, Le Traon Y, et al. Automatically securing permission-based software by reducing the attack surface:An application to Android[C]∥Proc of the 27th IEEE/ACM International Conference on Automated Software Engineering, 2012:274-277.

[6] Vidas T, Christin N, Cranor L. Curbing Android permission creep[C]∥Proc of the Web 2.0 Security and Privacy 2011, 2011:1.

[7] Wei X, Gomez L, Neamtiu I, et al. Permission evolution in the Android ecosystem[C]∥Proc of the 28th Annual Computer Security Applications Conference, 2012:31-40.

[8] Yang Bo, Tang Zhu-shou, Zhu Hao-jin, et al. Method of Android applications permission detection based on static dataflow analysis[J]. Computer Science, 2012, 39(11A):16-18.(in Chinese)

[9] Enck W, Ongtang M, McDaniel P. On lightweight mobile phone application certification[C]∥Proc of the 16th ACM Conference on Computer and Communications Security, 2009:235-245.

[10] Barrera D, Kayacik H G, van Oorschot P C, et al. A methodology for empirical analysis of permission-based security models and its application to Android[C]∥Proc of the 17th ACM conference on Computer and Communications Security, 2010:73-84.

[11] Peng H, Gates C, Sarma B, et al. Using probabilistic generative models for ranking risks of Android apps[C]∥Proc of the 2012 ACM Conference on Computer and Communications Security, 2012:241-252.

[12] Pearce P, Felt A P, Nunez G, et al. AdDroid:Privilege separation for applications and advertisers in Android[C]∥Proc of the 7th ACM Symposium on Information, Computer and Communications Security, 2012:71-72.

[13] Zhang Y, Yang M, Xu B, et al. Vetting undesirable behaviors in Android apps with permission use analysis[C]∥Proc of the 2013 ACM SIGSAC Conference on Computer & Communications Security, 2013:611-622.

[14] Yang Huan, Zhang Yu-qing, Hu Yu-pu, et al. A malware behavior detection system of Android applications based on multi-class features[J]. Chinese Journal of Computers, 2014, 37(1):15-27.(in Chinese)

[15] Zhang Rui, Yang Ji-yun. Android malware detection based on permission correlation[J]. Journal of Computer Applications, 2014, 34(5):1322-1325.(in Chinese)

[16] Nauman M,Khan S,Zhang X.Apex:Extending Android permission model and enforcement with user-defined runtime constraints[C]∥Proc of the 5th ACM Symposium on Information, Computer and Communications Security, 2010:328-332.

[17] Bao Ke-jin, Peng Zhao. An extended Android application permission management model[J]. Computer Engineering , 2012, 38(18):57-60.(in Chinese)

[18] Xu R, Sa?di H, Anderson R. Aurasium:Practical policy enforcement for Android applications[C]∥Proc of the 21st USENIX Conference on Security Symposium, 2012:27.

[19] Livshits B, Jung J. Automatic mediation of privacy-sensitive resource access in smartphone applications[C]∥Proc of the 22nd USENIX Security Symposium, 2013:113-130.

[20] Smalley S, Craig R. Security enhanced (se) Android:Bringing flexible MAC to Android[C]∥Proc of the 20th Annual Network and Distributed System Security Symposium (NDSS’13), 2013:1.

[21] Bugiel S, Heuser S, Sadeghi A R. Flexible and fine-grained mandatory access control on Android for diverse security and privacy policies[C]∥Proc of the 22nd USENIX Security Symposium (USENIX Security’13), 2013:131-146.

[22] Bugiel S,Davi L,Dmitrienko A,et al.Practical and lightweight domain isolation on Android[C]∥Proc of the 1st ACM Workshop on Security and Privacy in Smartphones and Mobile Devices, 2011:51-62.

[23] Ongtang M, McLaughlin S, Enck W, et al. Semantically rich application-centric security in Android[J]. Security and Communication Networks, 2012, 5(6):658-673.

[24] Tang Wei.Research and improvement on Android framwork’s security enforcement[D]. Ningbo:Ningbo University, 2011. (in Chinese)

[25] Smali [EB/OL].[2014-05-16]. https://code.google.com/p/smali/.

[26] axml [EB/OL].[2014-05-16]. https://code.google.com/p/axml/.

[27] Google Play[EB/OL].[2014-05-16]. https://play.google.com/store.

附中文參考文獻：

[8] 楊博, 唐祝壽, 朱浩謹, 等. 基于靜態數據流分析的Android

應用權限檢測方法[J]. 計算機科學,2012, 39(11A):16-18.

[14] 楊歡, 張玉清, 胡予濮, 等. 基于多類特征的Android應用惡意行為檢測系統[J]. 計算機學報, 2014, 37(1):15-27.

[15] 張銳, 楊吉云. 基于權限相關性的Android惡意軟件檢測[J]. 計算機應用, 2014, 34(5):1322-1325.

[17] 鮑可進, 彭釗. 一種擴展的Android應用權限管理模型[J]. 計算機工程,2012, 38(18):57-60.

[24] 湯偉. Android應用程序框架安全機制研究及改進[D].寧波:寧波大學, 2011.

BAIXiao-long,born in 1989,PhD candidate,CCF member(E200037503G),his research interest includes mobile security.

《計算機工程與科學》征文通知

《計算機工程與科學》是由國防科技大學計算機學院主辦的中國計算機學會會刊，是國內外公開發行的計算機類綜合性學術刊物，現為月刊。 本刊歡迎關于計算機科學理論、計算機組織與系統結構、計算機軟件、計算機應用、計算機器件設備與工藝等學科領域方面的來稿。本刊每年出版一期高性能計算?？⑶页Ｄ暝O有高性能計算專欄。

來稿論文必須未發表、未投到其他會議或期刊。

來稿要求和注意事項：

(1) 主題明確、文字精練、語句通順、數據可靠。

(2) 標題、作者單位、摘要、關鍵詞采用中英文間隔行文；請注明是否基金資助項目論文(注明項目名稱和編號) ，并注明文章中圖法分類號。務必附上所有作者中英文簡歷(姓名、性別、出生年月、籍貫、學位、職稱、研究方向) 、1寸證件照片(軍人請用便服照)、中英文通信地址、聯系電話和Email 。

(3) 作者在投稿時須注明是否是CCF會員(高級會員、普通會員、學生會員) ,若是會員,請注明會員號。第一作者是CCF會員的，將享受8.5折的版面費優惠。

(4) 來稿請用WORD軟件編輯，格式為A4 ， 40行×40列，通欄排版，正文為5 號宋體,論文長度不得低于5個標準版面，并請自留底稿。

(5) 來稿中圖形繪制要求工整、清晰、緊湊，尺寸要適當，圖中文字用6 號宋體，線為0.5 磅。

(6) 每篇論文格式要求:1 引言；……；最后是結束語。引言和結束語中盡量不用圖和表。附錄應放參考文獻之后。參考文獻限已公開發表的。

(7) 來稿文責自負，要遵守職業道德，如摘引他人作品，務請在參考文獻中予以著錄。署名的作者應為參與創作，對內容負責的人。文章發表后，如不同意其他報、刊、數據庫等轉載、摘編其作品，請在來稿時聲明。

(9)本刊對來稿按100元/篇的標準收取稿件審理費。對已決定刊用的稿件按230元/頁的標準收取版面費。稿件刊登后，按國家有關規定酌致稿酬(含與本刊簽約的其他出版物轉摘的稿酬)，同時贈送當期樣刊兩本。

聯系地址：410073 湖南省長沙市國防科技大學《計算機工程與科學》編輯部

聯系電話：0731-84576405 電子郵件：jsjgcykx@163.net

投稿主頁：http://www.joces.org.cn

AsystemforautomaticallytailoringAndroidapplications’permissions

BAI Xiao-long

(Department of Computer Science and Technology,Tsinghua University,Beijing 100084,China)

Android uses the permission system to control application access.In the permission system,applications have to declare relevant permissions before they access some system resources.To be secure and trusted,applications should follow the principle of least privilege.However,in reality,many applications do not follow this principle,which may bring security threats.To solve this problem, we design and implement a novel system for automatically tailoring Android applications’permissions,called PTailor. PTailor analyzes and modifies the Android application installation file (APK file) so as to make it follow the principle of least privilege.Firstly,PTailor extracts the system API calls from the APK file and gets the API’s corresponding required permissions from a predefined API-to-permissions map.In this way,PTailor can get the shortest permission list that this application really requires.PTailor uses this permission list to match the application’s permission declaration file and removes those unused permissions.At last,the modified permission declaration file and the original code file are zipped to a new APK file that follows the principle of least privilege without changing its structure and semantics.PTailor is used to process 1246 Android applications in order to evaluate its performance.The experimental results show that APK files can be processed in a short time and PTailor has little influence on most tailored applications.

Android application;the principle of least privilege;overprivileged;automatically tailor permissions

1007-130X(2014)11-2074-13

2014-06-11;

：2014-08-16

國家863高技術研究發展計劃資助項目(2011AA01A203)

TP316

：A

10.3969/j.issn.1007-130X.2014.11.005

白小龍(1989),男，吉林集安人，博士生，CCF會員(E200037503G),研究方向為手機安全。E-mail:baixiaol@sina.com

通信地址：100084 北京市海淀區清華大學西主樓1區417

Address:Room 1-417,West Main Building,Tsinghua University,Haidian District,Beijing 100084,P.R.China