白小龍

(清華大學(xué)計(jì)算機(jī)系，北京 100084)

Android應(yīng)用程序權(quán)限自動(dòng)裁剪系統(tǒng)*

白小龍

(清華大學(xué)計(jì)算機(jī)系，北京 100084)

Android系統(tǒng)使用權(quán)限機(jī)制對(duì)應(yīng)用程序進(jìn)行控制，即應(yīng)用程序需要使用哪些系統(tǒng)資源就必須提前聲明相應(yīng)的權(quán)限。為了確保安全性和可靠性，應(yīng)用程序聲明權(quán)限時(shí)應(yīng)該滿(mǎn)足最小特權(quán)原則，即只聲明其所需要使用到的最少權(quán)限，但現(xiàn)實(shí)中有很多應(yīng)用存在權(quán)限過(guò)度聲明的現(xiàn)象，給用戶(hù)帶來(lái)安全隱患。提出了一種Android應(yīng)用程序權(quán)限自動(dòng)裁剪系統(tǒng)PTailor，通過(guò)對(duì)Android應(yīng)用程序安裝文件(APK文件)進(jìn)行分析和修改，使其滿(mǎn)足最小特權(quán)原則。PTailor首先從APK文件中提取程序所調(diào)用的所有系統(tǒng)API，并在預(yù)先生成的API權(quán)限映射表中查找該API所對(duì)應(yīng)的系統(tǒng)權(quán)限，從而得到應(yīng)用程序?qū)嶋H使用到的最少權(quán)限列表。然后根據(jù)該權(quán)限列表對(duì)程序的權(quán)限聲明文件進(jìn)行修改，裁剪掉已聲明但未使用的權(quán)限。最后將裁剪過(guò)的權(quán)限聲明文件與程序的其他部分重新合并成新的APK文件，新的APK文件中除了所聲明權(quán)限滿(mǎn)足最小特權(quán)原則外，其結(jié)構(gòu)和語(yǔ)義都沒(méi)有發(fā)生改變。使用PTailor對(duì)現(xiàn)實(shí)中的1 246個(gè)Android應(yīng)用進(jìn)行權(quán)限裁剪實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果表明，PTailor能夠在很短的時(shí)間內(nèi)完成權(quán)限分析和裁剪，而且大多數(shù)被裁剪的程序都能夠正確運(yùn)行。

Android應(yīng)用程序；最小特權(quán)原則；權(quán)限過(guò)度聲明；權(quán)限自動(dòng)裁剪

1 引言

近年來(lái)，隨著智能手機(jī)的普及率不斷提高，手機(jī)安全問(wèn)題越來(lái)越引起人們的重視。越來(lái)越多的手機(jī)應(yīng)用程序給用戶(hù)帶來(lái)便利的同時(shí)，也存儲(chǔ)著越來(lái)越多的用戶(hù)隱私數(shù)據(jù)，因此，手機(jī)應(yīng)用程序的安全性和可靠性尤為重要。

智能手機(jī)中，Android手機(jī)占有了巨大的市場(chǎng)份額。根據(jù)市場(chǎng)調(diào)研機(jī)構(gòu)Strategy Analytics的最新研究報(bào)告[1]，2013年Android手機(jī)占全球智能手機(jī)市場(chǎng)份額高達(dá)79%，增幅達(dá)62%。但是，由于系統(tǒng)開(kāi)源性和應(yīng)用市場(chǎng)開(kāi)放性，Android平臺(tái)極易遭到攻擊。而且由于Android應(yīng)用程序的編寫(xiě)沒(méi)有明確的規(guī)范，這使得Android應(yīng)用程序的安全性和可靠性良莠不齊。

Android系統(tǒng)使用一種權(quán)限機(jī)制來(lái)對(duì)應(yīng)用程序進(jìn)行訪(fǎng)問(wèn)控制，應(yīng)用程序想要通過(guò)系統(tǒng)提供的API進(jìn)行某種操作或使用某種資源，就必須具有與該API相對(duì)應(yīng)的權(quán)限。這些權(quán)限必須聲明在程序的AndroidManifest.xml文件中，該文件作為應(yīng)用的重要組成部分在應(yīng)用被安裝時(shí)由系統(tǒng)進(jìn)行檢查并提醒用戶(hù)該應(yīng)用具體聲明了哪些權(quán)限。應(yīng)用程序在進(jìn)行操作或使用資源時(shí)，Android系統(tǒng)會(huì)檢查其是否已聲明過(guò)相應(yīng)的權(quán)限。例如，從圖1的代碼段中可以看出，應(yīng)用程序需要使用TelephonyManager的getDeviceId()函數(shù)來(lái)獲取設(shè)備編號(hào)，并使用SmsManager的sendTextMessage()函數(shù)來(lái)發(fā)送短信，則該應(yīng)用程序必須在其AndroidManifest.xml文件中聲明READ_PHONE_STATE和SEND_SMS權(quán)限(如圖2所示)，而系統(tǒng)會(huì)在該應(yīng)用被安裝時(shí)提醒用戶(hù)該應(yīng)用將讀取手機(jī)狀態(tài)和ID并發(fā)送短信(如圖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 應(yīng)用程序使用系統(tǒng)資源代碼段

Figure 2 Xml segment of permission declaration

圖2 應(yīng)用程序權(quán)限聲明xml文檔段

Figure 3 Screenshot of permission notification while installation圖3 應(yīng)用程序安裝權(quán)限提醒截圖

開(kāi)發(fā)者在編寫(xiě)Android應(yīng)用程序時(shí)應(yīng)該遵循最小特權(quán)原則，即進(jìn)行哪些操作或者使用哪些資源，就只聲明與這些操作和資源相關(guān)的權(quán)限，而不應(yīng)該聲明過(guò)多不使用的權(quán)限。但是，很多開(kāi)發(fā)者并沒(méi)有遵循這一原則，造成了權(quán)限過(guò)度聲明，文獻(xiàn)[2]分析了940個(gè)Android應(yīng)用，發(fā)現(xiàn)有323個(gè)聲明了不使用的過(guò)多權(quán)限。過(guò)度聲明的權(quán)限不僅會(huì)給用戶(hù)帶來(lái)誤解，使用戶(hù)對(duì)程序的可靠性和個(gè)人隱私的保密性產(chǎn)生懷疑，而且會(huì)帶來(lái)安全隱患。當(dāng)權(quán)限過(guò)度聲明的應(yīng)用程序存在bug時(shí)，這些程序可能會(huì)被其他惡意程序利用，從而對(duì)用戶(hù)隱私或手機(jī)安全造成威脅。導(dǎo)致Android應(yīng)用程序權(quán)限過(guò)度聲明的主要原因有以下幾點(diǎn)：

(1)Android文檔不完善。Android文檔未給出每個(gè)API所需的權(quán)限，有些文檔給出的API權(quán)限信息甚至是錯(cuò)誤的。文獻(xiàn)[2]對(duì)Android 2.2進(jìn)行分析發(fā)現(xiàn)，一共有1 259個(gè)API需要使用權(quán)限，但是，Android文檔只描述了其中的78個(gè)，其中有6個(gè)API所描述的權(quán)限與其實(shí)際所使用到的權(quán)限不符。

(2)權(quán)限名稱(chēng)很接近，容易混淆。例如ACCESS_NETWORK_STATE和ACCESS_WIFI_STATE，從名稱(chēng)看兩者都是訪(fǎng)問(wèn)網(wǎng)絡(luò)的狀態(tài)，但實(shí)際上兩者被用于不同的API中，程序員由于不清楚兩者的具體含義，很容易同時(shí)聲明這兩個(gè)權(quán)限。

(3)Android允許應(yīng)用程序請(qǐng)求其他應(yīng)用程序進(jìn)行某些操作，這些被請(qǐng)求的應(yīng)用需要具有相關(guān)的權(quán)限，但進(jìn)行請(qǐng)求的應(yīng)用并不需要這一權(quán)限。例如，應(yīng)用可以請(qǐng)求瀏覽器打開(kāi)某一個(gè)URL，這時(shí)該應(yīng)用并不需要INTERNET權(quán)限，因?yàn)樵L(fǎng)問(wèn)網(wǎng)絡(luò)的行為并不是由該應(yīng)用完成的。有些開(kāi)發(fā)者并不了解這點(diǎn)，導(dǎo)致了聲明不必要的權(quán)限。

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

本文的主要貢獻(xiàn)和創(chuàng)新點(diǎn)如下：

(1)提出了一種Android應(yīng)用程序權(quán)限自動(dòng)裁剪系統(tǒng)PTailor，PTailor通過(guò)對(duì)Android應(yīng)用程序文件進(jìn)行分析和修改使其滿(mǎn)足最小特權(quán)原則。并通過(guò)實(shí)驗(yàn)對(duì)PTailor的權(quán)限裁剪性能、裁剪后可用性進(jìn)行了評(píng)測(cè)。

(2)通過(guò)實(shí)驗(yàn)結(jié)果，對(duì)Android應(yīng)用程序權(quán)限過(guò)度聲明現(xiàn)象和發(fā)展趨勢(shì)進(jìn)行了分析，并對(duì)以往關(guān)于API權(quán)限分析工作的完整性進(jìn)行了分析。

本文的具體內(nèi)容組織如下：第2節(jié)介紹國(guó)內(nèi)外與Android權(quán)限相關(guān)的研究現(xiàn)狀；第3節(jié)將對(duì)Android權(quán)限等背景知識(shí)進(jìn)行介紹；第4節(jié)重點(diǎn)介紹PTailor系統(tǒng)的組成模塊，并對(duì)各模塊的具體功能和算法進(jìn)行詳細(xì)的闡述；第5節(jié)闡述了實(shí)驗(yàn)設(shè)計(jì)以及結(jié)果分析，從多方面對(duì)PTailor系統(tǒng)進(jìn)行了評(píng)測(cè)；第6節(jié)對(duì)PTailor設(shè)計(jì)和實(shí)驗(yàn)中的一些問(wèn)題進(jìn)行討論，并對(duì)未來(lái)的工作進(jìn)行展望；第7節(jié)對(duì)全文進(jìn)行總結(jié)。

2 相關(guān)工作

Android系統(tǒng)采用權(quán)限機(jī)制對(duì)應(yīng)用程序進(jìn)行管理和控制，應(yīng)用在安裝時(shí)必須聲明與其所使用到的資源相關(guān)的權(quán)限，且只能使用所聲明過(guò)的權(quán)限范圍內(nèi)的資源。這一機(jī)制簡(jiǎn)單但控制能力有限，而且安裝時(shí)聲明權(quán)限的方式無(wú)論對(duì)于開(kāi)發(fā)者還是用戶(hù)都具有一定的局限性。國(guó)內(nèi)外有很多學(xué)者針對(duì)這一權(quán)限管理機(jī)制的使用現(xiàn)狀進(jìn)行分析或者提出更加有效的管理方式。

2.1 API權(quán)限映射分析相關(guān)工作

由于Android文檔對(duì)于大多數(shù)API所需權(quán)限沒(méi)有明確的解釋?zhuān)瑢?dǎo)致了很多權(quán)限過(guò)度聲明現(xiàn)象的發(fā)生。因此，研究API與其所需權(quán)限的映射，并分析現(xiàn)有應(yīng)用程序中權(quán)限過(guò)度聲明情況很有必要。

Felt A P等人[2]通過(guò)單元測(cè)試的方式分析了Android 2.2.1中的API權(quán)限映射關(guān)系，發(fā)現(xiàn)了1 259個(gè)API在使用時(shí)需要聲明權(quán)限，但是，Android 2.2的文檔中只給出了78個(gè)API的權(quán)限使用說(shuō)明。同時(shí)，他們提出了Stowaway工具，用于檢查應(yīng)用程序的權(quán)限過(guò)度聲明情況。并使用Stowaway對(duì)940個(gè)Android應(yīng)用進(jìn)行了分析，發(fā)現(xiàn)約三分之一(323)的應(yīng)用存在權(quán)限聲明但未使用的情況，并分析出產(chǎn)生這種現(xiàn)象的主要原因是Android文檔的不完整。在此項(xiàng)研究基礎(chǔ)上，F(xiàn)elt A P等人還對(duì)權(quán)限系統(tǒng)的設(shè)計(jì)提出了一些指導(dǎo)意見(jiàn)[3]。

Au K W Y等人[4]提出PScout系統(tǒng),通過(guò)對(duì)Android系統(tǒng)權(quán)限檢查部分源碼進(jìn)行靜態(tài)分析的方式分析了API與其權(quán)限的映射關(guān)系，并分析了四個(gè)版本的Android系統(tǒng)中API與其權(quán)限的對(duì)應(yīng)情況，包括隱藏的系統(tǒng)API和顯式的通用API。同時(shí)，他們還通過(guò)模糊測(cè)試的方式對(duì)1 260個(gè)應(yīng)用程序進(jìn)行了權(quán)限聲明檢查，發(fā)現(xiàn)543個(gè)應(yīng)用聲明了額外未使用的權(quán)限。

相似地，Bartel A等人[5]提出了COPES系統(tǒng),使用基于call graph的靜態(tài)分析從Android 系統(tǒng)框架中提取出函數(shù)調(diào)用與所需權(quán)限的對(duì)應(yīng)關(guān)系。對(duì)Android 2.2進(jìn)行分析，發(fā)現(xiàn)共有9 562個(gè)函數(shù)需要聲明權(quán)限。但是，不同于PScout的是，該工作只分析了API函數(shù)調(diào)用中的權(quán)限，沒(méi)有考慮到Intent和Content Provider等其他情況下所需的權(quán)限。

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

Wei X等人[7]使用Stowaway工具對(duì)237個(gè)應(yīng)用的1 703個(gè)版本的權(quán)限聲明演化過(guò)程進(jìn)行了分析，發(fā)現(xiàn)19.6%在新版本中存在權(quán)限過(guò)度聲明現(xiàn)象，25.2%在原本的版本中就已經(jīng)過(guò)度聲明?？傮w上呈現(xiàn)出權(quán)限過(guò)度聲明的應(yīng)用程序逐漸增多的趨勢(shì)。

Yang Bo等人[8]提出了一種基于數(shù)據(jù)流分析的靜態(tài)檢測(cè)工具Brox，用于檢測(cè)Android應(yīng)用程序是否聲明了過(guò)多的權(quán)限。

這些研究工作雖然都對(duì)Android系統(tǒng)中API與其權(quán)限的映射關(guān)系進(jìn)行了分析，或分析了應(yīng)用程序的權(quán)限過(guò)度聲明情況，但是都沒(méi)有運(yùn)用這一映射關(guān)系對(duì)應(yīng)用程序的權(quán)限過(guò)度聲明進(jìn)行控制，也沒(méi)有對(duì)過(guò)度聲明的權(quán)限進(jìn)行裁剪，無(wú)法確認(rèn)API權(quán)限映射以及應(yīng)用程序權(quán)限過(guò)度聲明分析結(jié)果的有效性。

2.2 Android權(quán)限其他相關(guān)研究

2.2.1 應(yīng)用程序的權(quán)限特征分析

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

2.2.2 權(quán)限使用控制或提醒相關(guān)研究

讓用戶(hù)了解或控制程序正在使用的權(quán)限對(duì)于保護(hù)用戶(hù)隱私很有幫助。Nauman M等人[16]提出了Apex架構(gòu)以及Bao Ke-jin等人[17]提出的權(quán)限管理模型，可以使用戶(hù)選擇將哪些權(quán)限賦予應(yīng)用程序，從而起到自主訪(fǎng)問(wèn)控制的作用。Xu R等人[18]提出的Aurasium系統(tǒng)可以在不修改Android源碼或獲得Root權(quán)限的情況下對(duì)應(yīng)用程序的API使用請(qǐng)求進(jìn)行用戶(hù)提醒和訪(fǎng)問(wèn)控制。Livshits B等人[19]在Windows Phone上添加了系統(tǒng)資源訪(fǎng)問(wèn)提醒，使得當(dāng)應(yīng)用程序訪(fǎng)問(wèn)某些系統(tǒng)資源時(shí)用戶(hù)會(huì)得到相應(yīng)的提醒，從而選擇允許或拒絕該訪(fǎng)問(wèn)。

2.2.3 應(yīng)用程序訪(fǎng)問(wèn)控制相關(guān)研究

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

3 背景介紹

3.1 Android權(quán)限機(jī)制

Android對(duì)系統(tǒng) API進(jìn)行權(quán)限檢查主要有三種情況：函數(shù)調(diào)用、Intent和Content Provider。

函數(shù)調(diào)用就是直接調(diào)用系統(tǒng)API函數(shù)從而使用某些資源，例如使用SmsManager類(lèi)中的sendTextMessage()函數(shù)來(lái)發(fā)送短信。

Intent是Android系統(tǒng)中進(jìn)程間通信的主要方式，即一個(gè)程序如果需要另一個(gè)程序完成某個(gè)工作，就需要向該程序發(fā)送一個(gè)具有特定Action參數(shù)的Intent。而請(qǐng)求一些系統(tǒng)程序時(shí)則需要具有相應(yīng)的權(quán)限才能發(fā)出Intent。例如，應(yīng)用請(qǐng)求使用撥號(hào)程序撥打電話(huà)，需要向撥號(hào)程序發(fā)送具有android.intent.action.CALL參數(shù)的Intent，則該應(yīng)用需要聲明android.permission.CALL_PHONE權(quán)限。

Content Provider存儲(chǔ)著一些數(shù)據(jù)信息，并向其他程序開(kāi)放用于獲取相關(guān)的數(shù)據(jù)。應(yīng)用程序如果需要獲取Content Provider中的數(shù)據(jù)，則需要通過(guò)不同的URL schema進(jìn)行請(qǐng)求，對(duì)于系統(tǒng)提供的某些Content Provider，應(yīng)用程序進(jìn)行請(qǐng)求時(shí)必須具有相應(yīng)的權(quán)限。例如，當(dāng)應(yīng)用程序使用schema為content://sms的URL請(qǐng)求讀取設(shè)備中的短信列表時(shí)就需要具有android.permission.READ_SMS權(quán)限。

3.2 APK文件

Android應(yīng)用程序使用Java語(yǔ)言編寫(xiě)并編譯成一種特殊的字節(jié)碼文件，稱(chēng)為Dalvik Bytecode，所有Java Class的Dalvik Bytecode合并在一起組成一個(gè)dex文件。除了dex文件，應(yīng)用還需要在一個(gè)AndroidManifest.xml文件中聲明應(yīng)用程序的組成部分以及所使用到的權(quán)限。這個(gè)AndroidManifest.xml文件與dex文件以及其他一些所需要使用到的資源文件通過(guò)JDK(Java Development Kit)中的jar工具打包并通過(guò)jarsigner工具使用開(kāi)發(fā)者私鑰進(jìn)行簽名，從而形成了Android應(yīng)用程序包文件(簡(jiǎn)稱(chēng)APK文件)，APK文件即為應(yīng)用程序的安裝文件。

4 PTailor系統(tǒng)

本文提出了一種Android應(yīng)用程序權(quán)限自動(dòng)裁剪的系統(tǒng)PTailor，PTailor主要采用靜態(tài)分析技術(shù)，對(duì)Android APK文件進(jìn)行分析和修改。PTailor由五個(gè)部分組成，包括API權(quán)限映射表生成模塊、APK分解模塊、API提取模塊、manifest裁剪模塊和APK合并模塊。PTailor系統(tǒng)架構(gòu)如圖4所示，對(duì)APK文件的分析和修改的流程如圖5所示。

Figure 4 Architecture of PTailor圖4 PTailor系統(tǒng)架構(gòu)圖

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

4.1 API權(quán)限映射表生成模塊

API權(quán)限映射表生成模塊負(fù)責(zé)讀取API權(quán)限映射數(shù)據(jù)文件，生成API與其權(quán)限的映射表，屬于系統(tǒng)的準(zhǔn)備工作。不同于其他模塊對(duì)每個(gè)APK文件都要運(yùn)行一次，該模塊對(duì)所有需要處理的APK文件只需要運(yùn)行一次即可。

4.1.1 API權(quán)限映射數(shù)據(jù)源

本文中，我們使用PScout[4]中得到的Android 4.1.1 API權(quán)限對(duì)應(yīng)結(jié)果數(shù)據(jù)作為API權(quán)限映射數(shù)據(jù)源。對(duì)應(yīng)于Android權(quán)限檢查機(jī)制的三種情況，這一數(shù)據(jù)源包括API函數(shù)調(diào)用與其所需權(quán)限對(duì)應(yīng)數(shù)據(jù)、Intent Action與其所需權(quán)限對(duì)應(yīng)數(shù)據(jù)、Content Provider URL schema與其所需權(quán)限對(duì)應(yīng)數(shù)據(jù)。PTailor同樣可以使用其他數(shù)據(jù)作為其API權(quán)限映射源，也可以由用戶(hù)自定義API權(quán)限的映射關(guān)系，但PScout的API權(quán)限映射關(guān)系是現(xiàn)階段最為完整的，故本文目前采用該數(shù)據(jù)。

4.1.2 API權(quán)限映射表數(shù)據(jù)結(jié)構(gòu)

PTailor使用散列表的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)API與其權(quán)限的映射關(guān)系，由于有些API會(huì)對(duì)應(yīng)多個(gè)權(quán)限，所以需要使用單個(gè)key對(duì)應(yīng)多個(gè)value的Multimap數(shù)據(jù)結(jié)構(gòu)，以API為key，以其所需權(quán)限為value。這個(gè)API與權(quán)限的映射表APM(API Permission Map)用于在API提取模塊中獲得所提取的API所對(duì)應(yīng)的權(quán)限。

4.2 APK分解模塊

APK分解模塊的主要工作是對(duì)Android應(yīng)用程序APK文件進(jìn)行解壓縮，從而獲得dex文件和AndroidManifest.xml文件。這兩個(gè)文件分別用于API提取模塊和manifest裁剪模塊當(dāng)中。API提取模塊通過(guò)遍歷dex文件來(lái)檢查所有API調(diào)用。manifest裁剪模塊通過(guò)API提取模塊中所得到的實(shí)際使用的權(quán)限列表對(duì)AndroidManifest.xml文件所聲明的權(quán)限進(jìn)行修改，裁剪掉那些已聲明但未使用的權(quán)限。經(jīng)過(guò)裁剪的AndroidManifest.xml文件與原始的dex文件最后一起通過(guò)APK合成模塊合成新的無(wú)權(quán)限過(guò)度聲明的APK文件。

4.3 API提取模塊

API提取模塊是PTailor的核心組成部分。其主要作用是從dex文件中提取所有使用到的權(quán)限。在3.1節(jié)中已經(jīng)介紹過(guò)，由于Android對(duì)API的權(quán)限檢查包括函數(shù)調(diào)用、Intent和Content Provider三種情況，所以PTailor的API提取模塊需要對(duì)這三種情況中所使用到的權(quán)限進(jìn)行分別提取。相對(duì)應(yīng)地，API提取模塊共分為三個(gè)子模塊，即函數(shù)調(diào)用提取模塊、Intent提取模塊和Content Provider提取模塊。這三個(gè)子模塊都以APK分解模塊中得到的dex文件和API權(quán)限映射表生成模塊中產(chǎn)生的API權(quán)限映射表APM作為輸入，輸出為應(yīng)用程序?qū)嶋H使用到的最小權(quán)限列表。

4.3.1 API函數(shù)調(diào)用提取模塊

API函數(shù)調(diào)用提取模塊的主要工作是提取程序中的所有函數(shù)調(diào)用，并在API權(quán)限映射表中查找所調(diào)用函數(shù)對(duì)應(yīng)的權(quán)限，將查找到的權(quán)限添加到輸出的已使用權(quán)限列表中。具體算法如算法1所示。

算法1API函數(shù)調(diào)用權(quán)限提取算法

輸入：Dalvik bytecode文件F，API權(quán)限映射表APM;

輸出：已使用的權(quán)限列表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權(quán)限映射表生成模塊中所獲得的API權(quán)限映射表APM，輸出為應(yīng)用程序所使用到的權(quán)限列表L。Android應(yīng)用程序是由多個(gè)Java Class組成的，而每個(gè)Class又是由多個(gè)Java Method組成的，每個(gè)Method中包含多個(gè)Dalvik指令(Instruction)，而只有invoke指令是函數(shù)調(diào)用指令，用于調(diào)用API函數(shù)。因此，算法1的第1～第3行中，API函數(shù)調(diào)用提取模塊遍歷每個(gè)Class的每個(gè)Method中的每個(gè)Instruction，并在第4、第5行檢查這個(gè)Instruction是不是invoke指令。如果是，則通過(guò)GetInvokedMethodWithClass()獲取invoke指令所調(diào)用的函數(shù)λ，λ中包括該函數(shù)的名稱(chēng)、參數(shù)以及所屬類(lèi)。算法在第7行判斷API權(quán)限映射表APM中是否有函數(shù)λ與其權(quán)限的映射，如果有，則在第8～第11行中，將APM中λ所對(duì)應(yīng)的所有權(quán)限加入到輸出的已使用權(quán)限列表L中。為了保證L為最小權(quán)限列表，AddToList()對(duì)于同一個(gè)權(quán)限只會(huì)添加一次。

如果APM中沒(méi)有函數(shù)λ的權(quán)限映射，則算法會(huì)在第13～第24行檢查λ是否有可能繼承自APM中的某個(gè)API。例如，使用類(lèi)X中的Z函數(shù)需要具有P權(quán)限，API權(quán)限映射表中包含(X:Z)→P的映射，但應(yīng)用程序并沒(méi)有直接使用類(lèi)X中的Z函數(shù)，而是通過(guò)類(lèi)Y繼承類(lèi)X，并調(diào)用Y中的Z函數(shù)。雖然Y并沒(méi)有對(duì)Z進(jìn)行重寫(xiě)，且調(diào)用類(lèi)Y中的Z函數(shù)同樣需要P權(quán)限，但在APM中不包含(Y:Z)→P的映射。為了處理這種情況，算法在第13、第14行分別提取函數(shù)λ的所屬類(lèi)α和函數(shù)名稱(chēng)β，在第23行回溯類(lèi)α的繼承關(guān)系鏈，并在第16行檢查APM中是否含有(α:β)的權(quán)限映射，如果沒(méi)有，則在第23行繼續(xù)回溯α，如果有，則在第17～第20行將APM中檢查到的權(quán)限列表加入到L中。API函數(shù)調(diào)用提取模塊回溯函數(shù)的繼承關(guān)系鏈的目的是防止由于某些應(yīng)用通過(guò)繼承系統(tǒng)服務(wù)的方式訪(fǎng)問(wèn)系統(tǒng)資源而導(dǎo)致的漏報(bào)。

4.3.2 Intent和Content Provider提取模塊

Intent提取模塊和Content Provider提取模塊分別用于提取應(yīng)用程序通過(guò)Intent方式和Content Provider方式獲取系統(tǒng)資源時(shí)所需要的權(quán)限。

Intent提取模塊提取程序發(fā)出Intent請(qǐng)求時(shí)的Action參數(shù)，并在API權(quán)限映射表中查找這些Action參數(shù)所對(duì)應(yīng)的權(quán)限，添加到已使用權(quán)限列表中。

Content Provider提取模塊提取程序發(fā)出的URL請(qǐng)求的schema，并在API權(quán)限映射表中查找這些schema所對(duì)應(yīng)的權(quán)限，添加到已使用權(quán)限列表中。

Action參數(shù)和URL schema都是字符串類(lèi)型，因此Intent和Content Provider提取模塊查找這兩個(gè)參數(shù)的方式是查找dex文件中是否有相應(yīng)的字符串。

4.4 manifest裁剪模塊

經(jīng)過(guò)API提取模塊獲得應(yīng)用程序?qū)嶋H使用的權(quán)限列表之后，PTailor通過(guò)manifest裁剪模塊對(duì)聲明了權(quán)限的AndroidManifest.xml文件進(jìn)行修改，裁剪掉已聲明但未使用的那些權(quán)限，從而達(dá)到最小特權(quán)原則。由于只修改manifest文件中權(quán)限聲明部分，且只刪除未使用過(guò)的權(quán)限聲明，所以PTailor的manifest裁剪模塊不會(huì)修改應(yīng)用程序的結(jié)構(gòu)。

4.5 APK合并模塊

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

5 實(shí)驗(yàn)設(shè)計(jì)與結(jié)果分析

PTailor系統(tǒng)主要使用Java和Python語(yǔ)言實(shí)現(xiàn)，其中，除API提取模塊中的Intent和Content Provider子提取模塊和APK合并模塊是使用Python語(yǔ)言實(shí)現(xiàn)外，其余模塊都使用Java實(shí)現(xiàn)。其中API函數(shù)調(diào)用提取模塊使用到了開(kāi)源項(xiàng)目dexlib2[25]對(duì)dex文件進(jìn)行遍歷，manifest裁剪模塊使用開(kāi)源項(xiàng)目axml[26]對(duì)二進(jìn)制的AndroidManifest.xml文件進(jìn)行修改。

本文通過(guò)實(shí)驗(yàn)對(duì)以下幾個(gè)方面進(jìn)行了評(píng)測(cè)和分析：PTailor系統(tǒng)的性能評(píng)測(cè)、裁剪后應(yīng)用程序可用性評(píng)測(cè)、應(yīng)用程序權(quán)限過(guò)度聲明分析、API權(quán)限映射數(shù)據(jù)源有效性分析。

5.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)中，我們對(duì)現(xiàn)實(shí)中的Android應(yīng)用程序APK文件使用PTailor進(jìn)行權(quán)限分析和裁剪，并進(jìn)行相應(yīng)的評(píng)測(cè)。實(shí)驗(yàn)數(shù)據(jù)集為Google Play[27]應(yīng)用商店27個(gè)應(yīng)用類(lèi)別中銷(xiāo)量前50的免費(fèi)應(yīng)用，去除掉重復(fù)的應(yīng)用，共1 246個(gè)APK文件。實(shí)驗(yàn)主機(jī)內(nèi)存為16 GB，CPU為8核Intel(R) Core(TM) i7-4770 CPU @ 3.40 GHz。PTailor系統(tǒng)的裁剪過(guò)程直接在實(shí)驗(yàn)主機(jī)上完成。裁剪后應(yīng)用程序可用性評(píng)測(cè)在實(shí)驗(yàn)主機(jī)上的一個(gè)Android 4.1.1模擬器中完成。

5.2 性能評(píng)測(cè)

我們對(duì)所有1 246個(gè)APK文件分別使用PTailor進(jìn)行權(quán)限分析和裁剪，并計(jì)算PTailor對(duì)每個(gè)APK文件進(jìn)行分析和修改的整體時(shí)間，以及每個(gè)模塊所占用的時(shí)間，從而評(píng)測(cè)PTailor的性能。由于API權(quán)限映射表生成模塊是PTailor系統(tǒng)中的準(zhǔn)備工作，不論APK文件數(shù)量多少，都只運(yùn)行一次，所以在性能評(píng)測(cè)實(shí)驗(yàn)中分析PTailor對(duì)APK文件的處理時(shí)間不考慮API權(quán)限映射表生成模塊的運(yùn)行時(shí)間。

PTailor可以成功地對(duì)所有1 246個(gè)APK文件進(jìn)行分析和裁剪，成功率為100%。所有APK文件的處理時(shí)間分布如圖6和圖7所示。圖6為處理時(shí)間分布柱狀圖，即橫坐標(biāo)為m的數(shù)據(jù)柱值n表示有n個(gè)APK文件可以在m-1到ms內(nèi)被PTailor處理完成。圖7為處理時(shí)間累積百分比折線(xiàn)圖，即橫坐標(biāo)為m的數(shù)據(jù)點(diǎn)的縱坐標(biāo)表示在ms內(nèi)能完成PTailor處理的APK個(gè)數(shù)百分比。從圖6中可以看出，所有的1 246個(gè)APK文件都能夠在20 s內(nèi)完成處理，而多數(shù)的APK文件的處理時(shí)間集中在2～7 s內(nèi)。從圖7中可以看出，有91.6%的APK文件可以在10 s內(nèi)完成處理。所以，PTailor可以在很短的時(shí)間內(nèi)對(duì)Android應(yīng)用程序進(jìn)行權(quán)限分析和裁剪，適用于在Google Play這種大量應(yīng)用程序集中的Android應(yīng)用市場(chǎng)中對(duì)應(yīng)用程序進(jìn)行自動(dòng)處理。

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

Figure 7 Cumulative percentage line graph of processing time圖7 APK文件總處理時(shí)間累積百分比折線(xiàn)圖

除了對(duì)每個(gè)APK的整體處理時(shí)間進(jìn)行統(tǒng)計(jì)，實(shí)驗(yàn)還對(duì)每個(gè)APK在各個(gè)模塊中的處理時(shí)間進(jìn)行了統(tǒng)計(jì)。除了API權(quán)限映射表生成模塊外，其他不同模塊的APK文件處理時(shí)間分布情況如表1～表4所示，其中不包括manifest裁剪模塊，因?yàn)楹芏鄳?yīng)用程序不存在過(guò)度聲明的權(quán)限，所以不需要進(jìn)行裁剪，且大多數(shù)需要裁剪的APK文件的裁剪時(shí)間都在1～2 ms之內(nèi)，由于時(shí)間過(guò)短，所以不做統(tǒng)計(jì)。

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

Table 2 Processing time of APIfunction call extracting module表2 API函數(shù)調(diào)用提取模塊處理時(shí)間分布表

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

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

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

5.3 可用性評(píng)測(cè)

可用性評(píng)測(cè)的目的是檢驗(yàn)PTailor對(duì)APK的裁剪是否過(guò)度，經(jīng)過(guò)裁剪的應(yīng)用是否依然能夠正常運(yùn)行。實(shí)驗(yàn)采用Android SDK中的自動(dòng)化壓力測(cè)試工具M(jìn)onkey。

Monkey通過(guò)將隨機(jī)生成的UI事件序列注入到應(yīng)用程序中的方式對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試。在Monkey中可以設(shè)置事件序列中的事件個(gè)數(shù)，并可以指定只針對(duì)某一個(gè)應(yīng)用進(jìn)行測(cè)試。同時(shí)，可以通過(guò)設(shè)置隨機(jī)種子的方式，指定UI事件序列的順序。Monkey在程序運(yùn)行結(jié)束后給出詳細(xì)的測(cè)試報(bào)告。如果應(yīng)用程序在某一個(gè)UI事件后崩潰，Monkey將停止測(cè)試并自動(dòng)退出，并報(bào)告該程序已經(jīng)崩潰。另外Monkey還有可能因?yàn)闊o(wú)法找到應(yīng)用程序的入口等原因而意外退出。使用Monkey進(jìn)行壓力測(cè)試的目的是檢查PTailor的裁剪是否會(huì)影響程序的可用性。

實(shí)驗(yàn)中，我們首先對(duì)所有未裁剪的APK文件進(jìn)行Monkey測(cè)試，每個(gè)測(cè)試的隨機(jī)事件個(gè)數(shù)為2 000，并記錄下對(duì)每個(gè)APK進(jìn)行測(cè)試時(shí)所使用的隨機(jī)種子seed。同時(shí)，我們還會(huì)記錄下未裁剪的應(yīng)用中崩潰的應(yīng)用以及導(dǎo)致Monkey測(cè)試失敗的應(yīng)用，這些未裁剪就已經(jīng)崩潰和意外退出的應(yīng)用是由其本身錯(cuò)誤或者與模擬器版本不兼容所導(dǎo)致的，對(duì)實(shí)驗(yàn)沒(méi)有意義，所以在之后對(duì)裁剪過(guò)的APK文件進(jìn)行Monkey測(cè)試時(shí)將不考慮這些已崩潰的應(yīng)用。

然后，我們對(duì)裁剪過(guò)的APK文件進(jìn)行Monkey測(cè)試。每個(gè)裁剪過(guò)的APK文件進(jìn)行測(cè)試時(shí)所使用的隨機(jī)種子與其對(duì)應(yīng)的未裁剪版本在進(jìn)行測(cè)試時(shí)所記錄下的隨機(jī)種子seed相同，這使得裁剪前和裁剪后的同一個(gè)APK文件在進(jìn)行Monkey測(cè)試時(shí)使用相同的UI事件序列。同樣地，我們也記錄下裁剪過(guò)的應(yīng)用程序中崩潰的以及導(dǎo)致Monkey意外退出的程序。這些應(yīng)用的崩潰可能是由于PTailor裁剪了過(guò)多權(quán)限所導(dǎo)致的，需要進(jìn)行進(jìn)一步分析。

在實(shí)驗(yàn)過(guò)程中，對(duì)每一個(gè)APK文件的測(cè)試都單獨(dú)進(jìn)行，每一次測(cè)試只安裝一個(gè)APK文件，對(duì)其進(jìn)行Monkey測(cè)試結(jié)束后，將該APK文件卸載，從而避免對(duì)實(shí)驗(yàn)環(huán)境的改變以及對(duì)其他應(yīng)用測(cè)試的影響。但是，在安裝APK文件時(shí)，也會(huì)有一些APK文件安裝失敗，因此我們也會(huì)記錄安裝失敗的APK文件，并只對(duì)安裝成功的APK文件進(jìn)行測(cè)試。整個(gè)實(shí)驗(yàn)過(guò)程如圖8所示。

Figure 8 Workflow of usability experiment圖8 可用性測(cè)試實(shí)驗(yàn)流程

在可用性測(cè)試結(jié)束后，對(duì)可用性測(cè)試結(jié)果進(jìn)行統(tǒng)計(jì)和總結(jié)。在對(duì)未裁剪的APK文件進(jìn)行Monkey測(cè)試時(shí)，共有73個(gè)APK文件安裝失敗，有202個(gè)APK文件崩潰或?qū)е翸onkey測(cè)試失敗。排除這些無(wú)意義的APK文件外，共有971個(gè)應(yīng)用程序在未裁剪時(shí)能成功運(yùn)行。對(duì)這971個(gè)應(yīng)用程序的裁剪后版本進(jìn)行Monkey測(cè)試，共有69個(gè)應(yīng)用程序崩潰，而這69個(gè)應(yīng)用程序中，有17個(gè)應(yīng)用程序在PTailor分析結(jié)果中并沒(méi)有權(quán)限過(guò)度聲明現(xiàn)象，因此，這17個(gè)應(yīng)用程序?qū)嶋H并沒(méi)有被裁剪，導(dǎo)致其崩潰的原因可能是網(wǎng)絡(luò)環(huán)境影響等因素，與PTailor權(quán)限裁剪無(wú)關(guān)。而剩余的52個(gè)崩潰的應(yīng)用程序，只占全部1 246個(gè)應(yīng)用程序的4.17%，占全部可運(yùn)行的971個(gè)應(yīng)用程序的5.35%，從而可以說(shuō)明PTailor的權(quán)限裁剪只會(huì)影響很少的Android應(yīng)用程序，大多數(shù)被裁剪的程序依然能夠正確運(yùn)行。

5.4 應(yīng)用程序權(quán)限過(guò)度聲明分析

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

Figure 9 Comparison of overprivileged applications圖9 權(quán)限過(guò)度聲明比例比較

在這811個(gè)權(quán)限過(guò)度聲明應(yīng)用程序中，30.57%的應(yīng)用只過(guò)度聲明了一個(gè)權(quán)限，49.25%的應(yīng)用過(guò)度聲明權(quán)限個(gè)數(shù)小于或等于2個(gè)，74.88%的應(yīng)用過(guò)度聲明權(quán)限個(gè)數(shù)小于或等于4個(gè)。具有不同過(guò)度聲明權(quán)限個(gè)數(shù)的應(yīng)用程序數(shù)量分布柱狀圖如圖10所示。

Figure 10 Distribution of overprivileged permissions圖10 應(yīng)用程序過(guò)度聲明權(quán)限個(gè)數(shù)分布柱狀圖

另外我們發(fā)現(xiàn)，在所有1 246個(gè)應(yīng)用程序中，有很多應(yīng)用聲明了名稱(chēng)以android.permission.和com.android.為開(kāi)頭但在Android系統(tǒng)中并不存在的權(quán)限。通常，名稱(chēng)以android.permission.和com.android.為開(kāi)頭的權(quán)限是Android的系統(tǒng)權(quán)限。這些以android.permission.和com.android.為開(kāi)頭但在Android系統(tǒng)中并不存在的權(quán)限可能是某些Android應(yīng)用程序自定義的權(quán)限，但是也有一些是根本不存在甚至是明顯書(shū)寫(xiě)錯(cuò)誤的權(quán)限。這些不存在或書(shū)寫(xiě)錯(cuò)誤的權(quán)限是由于程序開(kāi)發(fā)者的個(gè)人因素所導(dǎo)致的，應(yīng)該盡量避免。例如，

(1)與系統(tǒng)權(quán)限名稱(chēng)相近，但根本不存在的權(quán)限。程序如果希望讀取短信，則需要聲明READ_SMS權(quán)限，但有些應(yīng)用程序卻聲明了READ_MMS這個(gè)根本不存在的權(quán)限。

(2)無(wú)需聲明且根本不存在的權(quán)限。Android為每個(gè)應(yīng)用程序提供獨(dú)立私有的內(nèi)部存儲(chǔ)空間用于存儲(chǔ)數(shù)據(jù)，使用這個(gè)內(nèi)部空間并不需要聲明任何權(quán)限，但有些應(yīng)用程序卻聲明了READ_INTERNAL_STORAGE這個(gè)根本不存在的權(quán)限。

(3)書(shū)寫(xiě)錯(cuò)誤的權(quán)限。應(yīng)用程序如果要錄制音頻，則需要聲明RECORD_AUDIO權(quán)限，但有些應(yīng)用程序開(kāi)發(fā)者卻將這一權(quán)限錯(cuò)誤地書(shū)寫(xiě)成了RECORDE_AUDIO。

5.5 API權(quán)限映射數(shù)據(jù)源有效性分析

4.1.1節(jié)中提到，PTailor現(xiàn)階段的API權(quán)限映射數(shù)據(jù)源來(lái)自于PScout[4]的實(shí)驗(yàn)結(jié)果，據(jù)我們所知，PScout中所得到的API權(quán)限映射關(guān)系是目前最為完整的，其對(duì)Android 4.1.1的分析結(jié)果中包括了32 450個(gè)API函數(shù)直接調(diào)用權(quán)限映射，97個(gè)Intent Action權(quán)限映射和78個(gè)Content Provider URL schema權(quán)限映射，但經(jīng)過(guò)實(shí)驗(yàn)我們發(fā)現(xiàn)該數(shù)據(jù)源并不完善，存在很多缺陷。

5.5.1 權(quán)限覆蓋率分析

PScout對(duì)Android 4.1.1中的API權(quán)限映射進(jìn)行分析，共找到了101個(gè)權(quán)限與API有所映射，但Android 4.1.1系統(tǒng)中的所有權(quán)限個(gè)數(shù)為180個(gè)。其中，Android系統(tǒng)中有92個(gè)權(quán)限在PScout中沒(méi)有得到對(duì)應(yīng)，而在全部1 246個(gè)應(yīng)用中有137個(gè)程序所聲明的權(quán)限包含在這92個(gè)PScout未對(duì)應(yīng)的權(quán)限中。另外，PScout的API權(quán)限映射結(jié)果中，有13個(gè)權(quán)限是Android系統(tǒng)提供給系統(tǒng)級(jí)應(yīng)用程序的特殊權(quán)限，無(wú)法被普通應(yīng)用所使用。從以上結(jié)果中可以看出，PScout的權(quán)限覆蓋率僅為48.9%。

5.5.2 API映射分析

除了權(quán)限覆蓋不完整之外，PScout中的API權(quán)限映射關(guān)系也不完整。具體包括以下幾點(diǎn)：

(1)外部存儲(chǔ)設(shè)備訪(fǎng)問(wèn)權(quán)限。如果應(yīng)用程序想讀取或?qū)懭隨D卡中的文件，訪(fǎng)問(wèn)sdcard目錄，則該應(yīng)用必須具有READ_EXTERNAL_STORAGE或WRITE_EXTERNAL_STORAGE權(quán)限，同時(shí)為了對(duì)SD卡上的文件進(jìn)行操作，有些應(yīng)用程序還需要MOUNT_UNMOUNT_FILESYSTEMS權(quán)限。但是，PScout的API權(quán)限映射中沒(méi)有這些與SD卡文件操作相關(guān)的權(quán)限映射。

(2)WebView訪(fǎng)問(wèn)網(wǎng)絡(luò)權(quán)限。Android系統(tǒng)提供WebView組件用于顯示W(wǎng)eb頁(yè)面，任何使用WebView顯示W(wǎng)eb頁(yè)面的應(yīng)用程序都應(yīng)該具有INTERNET權(quán)限。WebView可以在程序的代碼段中動(dòng)態(tài)聲明，也可以在xml文件中靜態(tài)聲明。PScout的API權(quán)限映射結(jié)果中只包含WebView動(dòng)態(tài)聲明API，而沒(méi)有xml靜態(tài)聲明WebView的權(quán)限映射。

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

(4)漏報(bào)的API。PScout中雖然含有超過(guò)30 000個(gè)API與其權(quán)限的映射，但仍有一些需要權(quán)限的API沒(méi)有得到映射。例如，android.hardware.Camera中的open(int)函數(shù)需要CAMERA權(quán)限，但PScout中沒(méi)有該API的權(quán)限映射。

(5)不同參數(shù)對(duì)應(yīng)的權(quán)限。對(duì)于有些API函數(shù)，當(dāng)使用不同參數(shù)進(jìn)行函數(shù)調(diào)用時(shí)，其所需的權(quán)限可能不同。例如，當(dāng)應(yīng)用程序打開(kāi)一個(gè)具有TYPE_SYSTEM_ALERT參數(shù)的窗口，使窗口出現(xiàn)在所有其他窗口上時(shí)，程序應(yīng)該具有SYSTEM_ALERT_WINDOW權(quán)限。但是，PScout沒(méi)有函數(shù)調(diào)用參數(shù)的權(quán)限映射信息。

6 討論

6.1 應(yīng)用程序之間的請(qǐng)求

Android允許一個(gè)應(yīng)用程序請(qǐng)求另一個(gè)應(yīng)用程序進(jìn)行某個(gè)操作、完成某項(xiàng)任務(wù)，這種請(qǐng)求只能通過(guò)消息傳遞的方式進(jìn)行通知，而無(wú)法進(jìn)行直接的函數(shù)調(diào)用。由于程序之間不能夠直接調(diào)用函數(shù)，而且程序之間也不存在請(qǐng)求傳遞的關(guān)系，如果被請(qǐng)求方將請(qǐng)求方的系統(tǒng)資源請(qǐng)求直接轉(zhuǎn)發(fā)出去，則請(qǐng)求方和被請(qǐng)求方都應(yīng)該具有相應(yīng)的權(quán)限。因此，并不存在某一個(gè)應(yīng)用程序?yàn)槠渌麘?yīng)用程序預(yù)先申請(qǐng)權(quán)限、使得無(wú)權(quán)限一方調(diào)用有權(quán)限一方的情況，因此PTailor的裁剪不會(huì)影響程序之間的請(qǐng)求。

6.2 可用性評(píng)測(cè)方法局限性

5.3節(jié)中使用Monkey對(duì)PTailor裁剪后應(yīng)用程序的可用性進(jìn)行了評(píng)測(cè)。Monkey雖然可以通過(guò)隨機(jī)注入事件序列的方式對(duì)應(yīng)用程序進(jìn)行自動(dòng)化的壓力測(cè)試，但這種方法具有一定的局限性。由于Monkey的事件類(lèi)型和注入順序都是隨機(jī)的，所以使用Monkey測(cè)試并不能保證完全的代碼覆蓋率，可能導(dǎo)致測(cè)試的不完整，增加漏報(bào)率。但是，現(xiàn)階段還沒(méi)有代碼覆蓋率為100%的Android應(yīng)用程序自動(dòng)化測(cè)試方法，因此，本實(shí)驗(yàn)的漏報(bào)率還無(wú)法測(cè)量。在未來(lái)的工作中，我們將設(shè)計(jì)并提出代碼覆蓋率更高、更符合程序流程結(jié)構(gòu)的Android應(yīng)用程序自動(dòng)化測(cè)試方法。

6.3 導(dǎo)致裁剪后應(yīng)用程序不可用的原因

從5.3節(jié)的可用性評(píng)測(cè)結(jié)果中可以看出，PTailor的權(quán)限裁剪依然會(huì)影響很少一部分Android應(yīng)用程序的正常運(yùn)行。導(dǎo)致這一結(jié)果的主要原因有以下幾點(diǎn)：

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

(2)Java反射機(jī)制的影響。Android應(yīng)用程序使用Java語(yǔ)言編寫(xiě)，Java提供反射機(jī)制允許應(yīng)用程序在運(yùn)行時(shí)動(dòng)態(tài)地調(diào)用函數(shù)。PTailor的API函數(shù)調(diào)用提取模塊中沒(méi)有對(duì)反射機(jī)制的函數(shù)調(diào)用進(jìn)行分析，完整的反射機(jī)制函數(shù)調(diào)用分析需要進(jìn)行信息流敏感、跨函數(shù)的靜態(tài)分析。在未來(lái)的工作中，我們將在PTailor中增加對(duì)反射機(jī)制函數(shù)調(diào)用的靜態(tài)分析。

這些因素有可能引起PTailor由于無(wú)法找到某些權(quán)限在程序中所對(duì)應(yīng)的API而導(dǎo)致的權(quán)限過(guò)度裁剪，但是不會(huì)導(dǎo)致應(yīng)用程序過(guò)度聲明的權(quán)限沒(méi)有得到裁剪。即經(jīng)過(guò)PTailor裁剪的應(yīng)用程序權(quán)限集合，可能是其最小特權(quán)的子集，但不會(huì)是最小特權(quán)的超集。但是，由于現(xiàn)階段沒(méi)有完整的API權(quán)限映射數(shù)據(jù)，所以暫時(shí)無(wú)法證明經(jīng)過(guò)PTailor裁剪的權(quán)限集合是否與應(yīng)用程序的最小特權(quán)集合完全吻合。

7 結(jié)束語(yǔ)

Android應(yīng)用程序的權(quán)限聲明應(yīng)該滿(mǎn)足最小特權(quán)原則，但現(xiàn)實(shí)中的很多應(yīng)用程序聲明了過(guò)多不使用的權(quán)限，從而可能帶來(lái)安全隱患。本文提出了一種Android應(yīng)用程序權(quán)限自動(dòng)裁剪系統(tǒng)PTailor，PTailor在應(yīng)用程序中提取系統(tǒng)API調(diào)用信息，分析調(diào)用這些API所需的對(duì)應(yīng)權(quán)限，得到應(yīng)用程序?qū)嶋H所需要的最少權(quán)限，并將程序中多余的未被使用的權(quán)限裁剪掉，從而使得裁剪后的Android應(yīng)用程序滿(mǎn)足最小特權(quán)原則。使用PTailor對(duì)現(xiàn)實(shí)中的1 246個(gè)Android應(yīng)用程序進(jìn)行權(quán)限分析和裁剪實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果表明91.6%的APK文件能夠在10秒內(nèi)完成權(quán)限分析和裁剪，最長(zhǎng)的處理時(shí)間為20秒，并且PTailor的裁剪不會(huì)對(duì)大多數(shù)程序的運(yùn)行產(chǎn)生明顯影響。同時(shí)，文中還對(duì)應(yīng)用程序權(quán)限過(guò)度聲明趨勢(shì)進(jìn)行了分析，發(fā)現(xiàn)權(quán)限過(guò)度聲明的應(yīng)用程序數(shù)量隨時(shí)間呈現(xiàn)上升趨勢(shì)，且應(yīng)用程序存在因開(kāi)發(fā)者個(gè)人因素所導(dǎo)致的錯(cuò)誤權(quán)限聲明現(xiàn)象。另外，通過(guò)實(shí)驗(yàn)我們還發(fā)現(xiàn)，以往的API權(quán)限映射分析研究工作還存在很多不足和缺陷。

[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.

附中文參考文獻(xiàn)：

[8] 楊博, 唐祝壽, 朱浩謹(jǐn), 等. 基于靜態(tài)數(shù)據(jù)流分析的Android

應(yīng)用權(quán)限檢測(cè)方法[J]. 計(jì)算機(jī)科學(xué),2012, 39(11A):16-18.

[14] 楊歡, 張玉清, 胡予濮, 等. 基于多類(lèi)特征的Android應(yīng)用惡意行為檢測(cè)系統(tǒng)[J]. 計(jì)算機(jī)學(xué)報(bào), 2014, 37(1):15-27.

[15] 張銳, 楊吉云. 基于權(quán)限相關(guān)性的Android惡意軟件檢測(cè)[J]. 計(jì)算機(jī)應(yīng)用, 2014, 34(5):1322-1325.

[17] 鮑可進(jìn), 彭釗. 一種擴(kuò)展的Android應(yīng)用權(quán)限管理模型[J]. 計(jì)算機(jī)工程,2012, 38(18):57-60.

[24] 湯偉. Android應(yīng)用程序框架安全機(jī)制研究及改進(jìn)[D].寧波:寧波大學(xué), 2011.

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

《計(jì)算機(jī)工程與科學(xué)》征文通知

《計(jì)算機(jī)工程與科學(xué)》是由國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院主辦的中國(guó)計(jì)算機(jī)學(xué)會(huì)會(huì)刊，是國(guó)內(nèi)外公開(kāi)發(fā)行的計(jì)算機(jī)類(lèi)綜合性學(xué)術(shù)刊物，現(xiàn)為月刊。 本刊歡迎關(guān)于計(jì)算機(jī)科學(xué)理論、計(jì)算機(jī)組織與系統(tǒng)結(jié)構(gòu)、計(jì)算機(jī)軟件、計(jì)算機(jī)應(yīng)用、計(jì)算機(jī)器件設(shè)備與工藝等學(xué)科領(lǐng)域方面的來(lái)稿。本刊每年出版一期高性能計(jì)算專(zhuān)刊，并且常年設(shè)有高性能計(jì)算專(zhuān)欄。

來(lái)稿論文必須未發(fā)表、未投到其他會(huì)議或期刊。

來(lái)稿要求和注意事項(xiàng)：

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

(2) 標(biāo)題、作者單位、摘要、關(guān)鍵詞采用中英文間隔行文；請(qǐng)注明是否基金資助項(xiàng)目論文(注明項(xiàng)目名稱(chēng)和編號(hào)) ，并注明文章中圖法分類(lèi)號(hào)。務(wù)必附上所有作者中英文簡(jiǎn)歷(姓名、性別、出生年月、籍貫、學(xué)位、職稱(chēng)、研究方向) 、1寸證件照片(軍人請(qǐng)用便服照)、中英文通信地址、聯(lián)系電話(huà)和Email 。

(3) 作者在投稿時(shí)須注明是否是CCF會(huì)員(高級(jí)會(huì)員、普通會(huì)員、學(xué)生會(huì)員) ,若是會(huì)員,請(qǐng)注明會(huì)員號(hào)。第一作者是CCF會(huì)員的，將享受8.5折的版面費(fèi)優(yōu)惠。

(4) 來(lái)稿請(qǐng)用WORD軟件編輯，格式為A4 ， 40行×40列，通欄排版，正文為5 號(hào)宋體,論文長(zhǎng)度不得低于5個(gè)標(biāo)準(zhǔn)版面，并請(qǐng)自留底稿。

(5) 來(lái)稿中圖形繪制要求工整、清晰、緊湊，尺寸要適當(dāng)，圖中文字用6 號(hào)宋體，線(xiàn)為0.5 磅。

(6) 每篇論文格式要求:1 引言；……；最后是結(jié)束語(yǔ)。引言和結(jié)束語(yǔ)中盡量不用圖和表。附錄應(yīng)放參考文獻(xiàn)之后。參考文獻(xiàn)限已公開(kāi)發(fā)表的。

(7) 來(lái)稿文責(zé)自負(fù)，要遵守職業(yè)道德，如摘引他人作品，務(wù)請(qǐng)?jiān)趨⒖嘉墨I(xiàn)中予以著錄。署名的作者應(yīng)為參與創(chuàng)作，對(duì)內(nèi)容負(fù)責(zé)的人。文章發(fā)表后，如不同意其他報(bào)、刊、數(shù)據(jù)庫(kù)等轉(zhuǎn)載、摘編其作品，請(qǐng)?jiān)趤?lái)稿時(shí)聲明。

(9)本刊對(duì)來(lái)稿按100元/篇的標(biāo)準(zhǔn)收取稿件審理費(fèi)。對(duì)已決定刊用的稿件按230元/頁(yè)的標(biāo)準(zhǔn)收取版面費(fèi)。稿件刊登后，按國(guó)家有關(guān)規(guī)定酌致稿酬(含與本刊簽約的其他出版物轉(zhuǎn)摘的稿酬)，同時(shí)贈(zèng)送當(dāng)期樣刊兩本。

聯(lián)系地址：410073 湖南省長(zhǎng)沙市國(guó)防科技大學(xué)《計(jì)算機(jī)工程與科學(xué)》編輯部

聯(lián)系電話(huà)：0731-84576405 電子郵件：jsjgcykx@163.net

投稿主頁(yè)：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

國(guó)家863高技術(shù)研究發(fā)展計(jì)劃資助項(xiàng)目(2011AA01A203)

TP316

：A

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

白小龍(1989),男，吉林集安人，博士生，CCF會(huì)員(E200037503G),研究方向?yàn)槭謾C(jī)安全。E-mail:baixiaol@sina.com

通信地址：100084 北京市海淀區(qū)清華大學(xué)西主樓1區(qū)417

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