安全隔離的安卓應用虛擬化框架設計與實現

侯俊行，楊哲慜，楊 珉

(復旦大學 軟件學院，上海 201203) E-mail ：yangzhemin@fudan.edu.cn

1 引 言

Android是最受歡迎的移動操作系統.據IDC報告顯示，2017年第一季度，Android已占據全球市場份額的85.0%[1].Android擁有豐富的應用，截至2018年6月，其官方市場Google Play中應用數已達到3，300，000個[2].用戶在使用Android應用時，存在對這些應用進行定制化的需求.例如，運行多個Twitter應用實例以同時登陸多個賬號，改變游戲Pokeman Go獲得的地理位置信息.然而，越來越多的應用使用混淆、重打包檢測等技術，這加大了應用被修改的難度.

用戶對應用定制化需求的不斷增長，促使Android平臺上應用虛擬化的流行.一個虛擬化框架(宿主應用)，可以在內部創建一個受控的虛擬空間，在此空間內能夠運行任意Android應用(目標應用).目標應用無需在系統內安裝，并可同時運行多個實例.此外，無需重打包，框架便能方便地對目標應用進行修改，達到應用定制化目的.目前，“平行空間[3]”作為最受歡迎的虛擬化框架，在Google Play中的下載量已經超過了1，000萬次.

然而，前人研究工作[4]發現，現有虛擬化框架存在以下安全問題：在存儲隔離方面，目標應用可以任意讀取框架內其它應用私有文件，造成隱私數據的泄露；在權限隔離方面，框架申請了過多權限，目標應用在運行時能夠繼承這些權限，進行惡意提權.

在原生Android中，系統為每個應用賦予唯一的用戶ID(UID)，并與之進行綁定.基于應用UID，系統為每個應用構建一個沙箱，實現存儲和權限的隔離.在應用虛擬化使用場景下，框架內可能同時運行多個目標應用實例，但系統卻無法為每個實例創建不同的沙箱.在同一沙箱內運行所有的目標應用實例時，系統對其中一個實例賦予的權限會擴散給沙箱內所有的實例，進而使其他實例被過度授權.然而，在對目標應用進行定制化時，定制化代碼只有與應用運行在同一沙箱內，才能夠修改目標應用的行為.因此，Android原生沙箱機制無法直接用于應用虛擬化場景.

現有針對應用虛擬化的沙箱隔離方案中，Boxify[5]將目標應用運行在不同的被隔離進程[6]中，由Boxify對應用所使用的函數調用進行攔截和訪問控制，以達到安全隔離目的.但是，Boxify需要預先申請所有的系統權限，增大了受攻擊面.并且，Boxify同樣無法對定制化代碼進行隔離.此外，Boxify實現的虛擬化方案并不完善，系統內第三方應用無法使用隱式Intent[7]啟動Boxify內的目標應用.

基于上述情況，本文設計并實現了一個安全隔離的應用虛擬化框架SecureAppV.首先，我們通過修改系統，將Android應用沙箱分配以及權限管控粒度細化為應用組件級別，解決了原本必須通過安裝多個應用才能獲得不同沙箱的難題.基于此，框架為每個目標應用實例的運行創建不同的沙箱，并支持用戶使用自定義規則對沙箱權限進行管理，以實現目標應用存儲和權限的隔離.同時，SecureAppV利用宿主應用對沙箱間通訊進行代理轉發，并使用自定義規則對轉發過程進行管控.在定制化代碼和目標應用位于不同沙箱的情況下，實現應用定制目的.最后，我們為系統增加組件熱更新機制，應用在無需重裝的前提下，能夠對自身組件的IntentFilter屬性進行修改.框架利用此機制，處理第三方應用隱式Intent的請求.

本文所修改Android版本為android-6.0.1_r77，編譯后的系統和SecureAppV框架運行在Nexus 5測試機之上.為了測試框架的隔離效果，本文選取平行空間等5個具有代表性的虛擬化應用，以及VirtualApp[8]、DroidPlugin[9]兩個開源框架與SecureAppV進行對比.實驗結果表明，僅有SecureAppV能夠對框架內目標應用存儲和權限進行有效隔離.為了測試SecureAppV的可用性，本文將8個主流應用運行在框架內.實驗中，8個(100%)應用均能正常運行，且在運行過程中，0個(0%)應用出現崩潰現象.在性能測試實驗中，SecureAppV對框架內運行的應用僅帶來5.92%的性能損失，具有較強的實用性.

2 背景與相關工作

2.1 安卓隔離與訪問控制機制

Android使用沙箱機制對應用代碼和數據進行隔離.在應用安裝時，系統為每個應用賦予唯一的UID，并與之進行綁定.應用運行在獨立進程之中，擁有完整的Dalvik/ART虛擬機實例，從而實現代碼的隔離.應用使用系統調用獲取文件資源時，內核基于進程UID實現文件目錄的訪問控制，從而為每個應用開辟私有空間，實現數據的隔離.這個基于Linux進程隔離機制創建的環境被稱為沙箱.

此外，Android使用權限機制對應用行為進行管理.在程序進行敏感操作或者訪問受保護資源時，由系統對應用的權限進行檢查.權限按照保護級別分為正常權限、危險權限和簽名權限三種類型.其中，正常權限在清單文件中聲明后，在應用安裝時被系統默認授予，無需用戶授權，被稱為安裝時權限.危險權限也被稱為運行時權限，應用申請運行時權限時，在清單文件中顯式聲明后，還需要在運行時使用方法Activity.requestPermissions()動態申請.應用包名以及應用所請求權限會被包裝進一個Intent對象，由系統應用安裝器所處理.應用安裝器會彈出一個權限授權對話框供用戶進行選擇，并將用戶授權結果交予活動管理服務AMS，由AMS請求使用包管理服務PMS進行權限授權結果的記錄.對于簽名權限的獲取，應用需要擁有與系統相同的簽名證書.

2.2 安卓應用虛擬化

本文中所指應用虛擬化是一種在應用層實現的虛擬化方案.它基于動態代碼加載，使用反射、代理等技術手段在宿主應用內，為目標應用創建運行所需的上下文環境.

使用虛擬化框架，用戶能夠方便地對目標應用進行定制化.框架在運行時動態加載目標應用代碼，運行在自身進程空間之內.目標應用無需在系統中進行安裝，并可同時運行多個實例.同時，框架對目標應用與系統間的交互進行代理.例如，應用通過地理位置服務LocationManagerService在宿主進程內的本地代理對象LocationManager與之進行通信.宿主應用通過替換本進程內遠程服務的本地代理對象，修改服務中方法getLastKnownLocation()的返回值，可以改變應用獲取的真實地理位置信息.

2.3 現有虛擬化框架安全問題分析

圖1為應用虛擬化框架結構圖.其中，框架與目標應用運行在同一沙箱內，框架對目標應用的請求進行代理，系統無法對請求的發起者進行區分.因此，目標應用與框架具有相同的存儲訪問能力和權限授權狀態.任意目標應用都可以讀取框架內其它應用的私有文件，繼承框架授權的所有權限，進行敏感操作或訪問系統保護資源.

2.4 相關工作

現有沙箱隔離方案，主要分為應用層實現[10-13]和系統級擴展[14-17]兩種類型.

應用層方案中，Aurasium[10]為Android平臺提供了使用時權限動態授予機制.通過對應用安裝包進行二進制重寫，Aurasium能夠攔截應用內所有權限的使用行為，并在攔截到權限使用的行為后，彈出對話框要求用戶進行顯式的權限授予.RetroSkeleton[11]重寫安裝包后插入分析代碼，使用靜態以及動態方式分析函數調用，并支持用戶自定義規則對應用行為進行監控和攔截.應用層解決方案通過應用重打包，加入特定監控代碼，對應用行為進行約束.由于應用與監控代碼運行在同一個沙箱中，它們之間缺乏安全隔離，攻擊者可以使用本地代碼等方式篡改或者繞過上述管控措施.此外，重打包會破壞應用原有的簽名.

系統級方案中，DeepDroid[14]通過對Android核心系統服務和關鍵函數進行動態插樁，以阻止不信任應用發起的調用行為.FireDroid[15]通過動態插樁Zygote和系統啟動代碼，對第三方或者預裝應用行為進行監控，根據用戶定義規則進行攔截.系統級解決方案無需對應用進行修改，破壞其原有簽名；基于并擴展Android原生沙箱機制，具有很強的隔離效果.但此類方案無法為宿主應用內多個目標應用運行實例創建不同沙箱，無法在定制化代碼隔離的情況下對目標應用進行修改，因此無法用于應用虛擬化場景.

2.5 威脅模型

本文考慮以下兩種攻擊情形：惡意應用運行在虛擬化框架中，讀取框架內其他應用的私有文件；惡意應用在未取得相關權限授權的情況下，通過繼承框架權限，進行敏感操作或者訪問系統保護資源.本文認為系統及其內核是安全的，惡意應用無法攻破系統現有安全保護措施.

3 SecureAppV總體框架

圖2為SecureAppV框架概覽圖.其中，框架按照功能被劃分為以下三個模塊：

UID分配模塊.為了能夠在宿主應用運行時創建UID不同于自身的沙箱，系統首先為其分配多個UID.我們選擇在宿主應用清單文件內增加特定的標簽，以便應用在安裝時，系統能夠區分出宿主應用.接下來，系統為宿主應用分配多個UID，處理UID對應目錄創建的問題.

沙箱管理模塊.SecureAppV將每個目標應用實例運行在不同的沙箱內，并使用用戶自定義規則對每個沙箱的權限進行管控，實現沙箱間存儲和權限的隔離.沙箱間能夠按照用戶自定義規則進行靈活的通訊.基于此，定制化代碼在與目標應用位于不同沙箱的情況下，依然能夠對應用進行修改.

圖2 SecureAppV框架概覽Fig.2 Overview of SecureAppV framework

虛擬化管理模塊.在新建的沙箱內，框架主要需要處理以下三個問題：

1)如何從外部動態加載任意目標應用或定制化代碼.

2)如何對應用組件生命周期進行管理.

3)如何處理第三方應用使用隱式Intent啟動框架內目標應用的請求.

4 SecureAppV設計與實現

4.1 UID分配模塊

Android使用包管理服務PMS對應用進行安裝、卸載和查詢.在應用安裝時，PMS通過解析應用安裝包內清單文件，獲取應用使用包名、聲明組件、申請權限等信息.之后，PMS為該應用分配全局唯一的UID(此處，不考慮共享UID情況)，創建UID對應的文件目錄.最后，PMS將應用信息以及應用分配的UID寫入配置文件中.因此，在UID分配階段，我們需要對PMS進行修改，在宿主應用安裝時為其分配多個UID，創建UID對應的文件目錄，最后將應用分配的所有UID進行存儲.

4.1.1 宿主應用標記與解析

首先，我們在宿主應用清單文件中增加特定的標簽，以便應用在安裝時，PMS能夠區分出宿主應用.如圖3所示為增加的標簽，該標簽有“android：name”和“android：value”兩個屬性.其中，屬性“android：name”值設為預定字符串“dynamicUID”，表明應用需要申請多個UID；屬性“android：value”值“2”指定額外申請UID的數量.此外，我們還需修改PackageParser.parseMetaData()方法，以對此標簽進行解析處理.

圖3 宿主應用清單文件標記
Fig.3 Mark in the Manifest file of host app

4.1.2 UID分配

4.1.3 私有目錄創建

應用分配UID之后，PMS通過socket方式向守護進程Installed發送命令，為應用創建私有目錄并設置文件訪問權限.我們通過修改Installed，為目標應用也創建相應的文件目錄.圖4為宿主應用的私有文件目錄.其中，宿主應用UID為10052，并申請到10053和10054兩個額外UID.目錄10053和10054作為目標應用私有文件的根目錄，文件所有者以及用戶組均與UID相同，組外用戶只擁有文件的執行權限，從而實現目標應用存儲隔離.

圖4 宿主應用私有文件目錄Fig.4 Private file directories of host app

最后，我們修改Settings.writePackageLPr()方法，將宿主應用申請的所有UID寫入/data/system/目錄下文件packages.xml做持久化存儲.

4.2 沙箱管理模塊

活動管理服務AMS負責應用進程的管理以及權限的檢查任務.我們通過對AMS進行修改，在宿主應用運行時動態創建UID不同于宿主應用的進程沙箱，根據用戶自定義規則對沙箱授權權限進行管理.

4.2.1 沙箱創建

AMS在啟動應用組件時，如果組件所在進程尚未創建，AMS會請求Zygote進程為其創建運行所需的進程.Zygote進程是所有Android應用進程的父進程.它在/dev/socket目錄下創建一個名為zygote的本地套接字，在監聽到新進程創建請求時，Zygote進程使用系統調用fork()新建一個子進程，并設置子進程的UID.

宿主應用通過啟動應用內Service組件創建新進程，并通過此組件與新進程進行通訊.創建過程中，AMS會向PMS請求包含Service組件信息的ServiceInfo對象.使用此對象，AMS能夠獲取應用對應的ApplicationInfo對象，從而得到應用分配的所有UID.我們通過修改AMS，創建Service組件運行所需的進程后，設置進程UID為宿主應用申請的額外UID，從而創建出UID不同于宿主應用的進程沙箱.

4.2.2 權限設置

為了保證目標應用能夠正常運行，我們需要為應用賦予相應的權限.PMS為每個應用生成一個PackageSetting類型對象，對象中記錄著應用在清單文件中聲明的權限以及權限授權狀態.AMS在進行權限檢查時，將待檢應用UID以及所檢查權限交由PMS進行處理.PMS的checkUidPermission()方法根據UID檢索應用對應的PackageSetting對象，返回對象中保存的待檢權限的授權狀態.我們在PMS內建立目標應用UID與PackageSetting對象的映射關系.其中，PackageSetting對象記錄的權限授權狀態按照用戶自定義規則進行設置，這樣便完成了目標應用權限的設置.

圖5 用戶自定義權限規則Fig.5 User defined permission rules

SecureAppV支持用戶自定義規則對目標應用權限進行設置.圖5為自定義權限規則.標簽使用包名指定設置目標對象，子標簽和分別對目標應用允許或者禁止使用的權限進行聲明.默認規則下，SecureAppV按照應用清單文件中聲明的權限對目標應用進行賦值.其中，安裝時權限被默認授予，運行時權限需要用戶授權來授予.為此，我們在運行時權限的請求中加入目標應用的UID身份信息，以便PMS根據UID找到應用相應的PackageSetting對象，繼而進行權限授權的記錄.

4.2.3 沙箱間通訊

對于宿主應用創建的沙箱，SecureAppV支持沙箱之間進行通訊，由宿主應用根據用戶自定義規則對通訊進行代理轉發.基于此，定制化代碼在與目標應用位于不同沙箱的情況下，代碼依然能夠對應用進行修改.目前，框架支持定制化代碼修改目標應用訪問的系統服務以及應用內的文件.

對于系統服務的修改.Android提供的系統服務需要在ServiceManager中進行注冊，應用可使用服務名獲取遠程服務在本進程內的Binder代理對象.之后，應用使用這些代理對象訪問遠程系統服務.SecureAppV支持定制化代碼替換目標進程內系統服務的本地代理對象，以達到修改應用訪問系統服務的目的.如圖6所示為定制化代碼創建的系統剪貼板服務的代理對象HookedClipboardBinder，通過繼承類IClipboard.Stub實現服務提供的功能.該對象重寫了getPrimaryClip()方法，用以返回特定的剪貼板內容.框架向定制化代碼提供了接口，該接口能夠將代碼創建的可序列化傳輸對象HookedClipboardBinder，經宿主應用傳輸給目標應用.在目標進程內，框架使用反射等技術手段對剪貼板服務的本地代理對象進行替換.最終，目標應用得到的剪貼板內容將始終為字符串“you are hooked”.

圖6 定制化代碼創建的服務代理對象Fig.6 Proxy object of service created by customization codes

對于文件的修改.SecureAppV使用ARM Inline Hook[18]技術，對定制化代碼文件操作使用的系統調用進行攔截，并將攔截到的調用名和參數發送至宿主應用，由宿主應用在目標進程內代為執行.例如，系統調用int chown(const char *path，uid_t owner，gid_t group)可以改變文件或目錄的所有者和所屬用戶組.此調用接受三個參數，第一個參數path為所修改文件或目錄的路徑；第二個參數owner為修改后的用戶ID；第三個參數group為修改后的用戶組ID.當定制化代碼修改目標應用文件test.txt所有者時，最終系統使用chown調用完成該操作.框架攔截到此系統調用后，將調用名owner和調用參數，包括文件路徑以及修改后的用戶ID和用戶組ID發送至宿主應用.宿主應用使用目標進程內的Service組件執行chown()系統調用，從而完成對目標應用test.txt文件所有者的修改.

圖7為用戶自定義的通訊規則.其中，標簽的source和sink屬性分別為定制化代碼以及目標應用所屬包名.子標簽指定了定制化代碼能夠修改的服務名稱；子標簽通過文件名或文件后綴指定定制化代碼允許修改的目標應用文件.

圖7 用戶自定義通訊規則Fig.7 User defined communication rules

4.3 虛擬化管理模塊

4.3.1 動態代碼加載

Android應用安裝包是一個Zip格式的壓縮文件，由應用清單文件、DEX可執行文件和資源文件打包而成.應用在正常安裝后，安裝包內代碼和資源文件會存放在系統固定目錄內.應用主線程ActivityThread內維護著一個LoadedApk類型字段，LoadedApk存有加載應用使用的類加載器.系統使用此加載器，從指定目錄加載應用代碼和資源文件.為了能夠從指定位置加載目標應用或者定制化代碼，我們使用DexClassLoader類加載器，在生成類加載器實例時傳入所要加載代碼的位置信息，并加入到主線程之中.

4.3.2 組件生命周期管理

Android中，由AMS負責對應用組件生命周期進行管理.AMS運行在系統進程system_server內，使用Binder機制與應用進行通訊.AMS向應用發送控制命令消息后，由應用主線程對這些消息進行處理，完成組件類加載或者生命周期函數的回調.應用通過本進程內AMS服務的本地代理對象ActivityManagerNative與AMS進行交互.

圖8為SecureAppV對目標應用Activity組件生命周期處理的過程.對于其他組件，本文限于篇幅進行了省略.其中，ActivityManagerProxy和ActivityThreadProxy分別是ActivityManagerNative和ActivityThread的代理對象，我們對目標進程內原有對象進行替換，以便對目標應用與AMS之間的交互以及應用主線程操作進行攔截.樁組件是在宿主應用內預先聲明的Activity組件，并加載到目標進程之中.首先，在目標進程內使用startActivity()方法啟動目標應用Activity組件(①)時，Intent對象內攜帶待啟動組件的信息.ActivityManagerProxy攔截到此方法調用后，檢索可用樁組件(②)，將Intent內待啟動目標應用組件替換為可用樁組件(③)，并維護樁組件與目標應用組件間的映射關系(④).之后，交由AMS進行組件的啟動(⑤)，以繞過目標組件未聲明使用的限制.AMS完成組件啟動準備工作后，向目標應用發送啟動樁組件的命令(⑥).ActivityThreadProxy攔截此命令后，根據映射關系完成啟動對象的轉換(⑦)，啟動相應的目標應用組件(⑧)，完成組件類的實例化(⑨).此后，由ActivityThreadProxy和樁組件共同完成目標組件生命周期函數的管理.例如，AMS需要銷毀樁組件時，請求主線程調用onDestroy()函數(⑩).ActivityThreadProxy根據映射關系，最終回調目標應用組件onDestroy()生命周期函數().

圖8 組件Activity生命周期管理Fig.8 Lifecycle management of Activity component

為了能夠對隱式Intent做出處理，SecureAppV使用樁組件并設置相應的Intent Filter屬性，對第三方應用啟動目標組件的隱式Intent進行響應()，并完成匹配().在應用虛擬化場景下，加載的目標應用具有任意性，無法預先對樁組件的Intent Filter屬性進行設置.由于PMS存儲應用組件以及組件的Intent Filter屬性，使用AIDL定義PMS對外提供的接口.因此，我們通過修改相應的AIDL文件(IPackageManager.aidl)，增加更新組件Intent Filter屬性值的方法int updateActivityIntentFilter(String name，List newFilters).其中，參數name為待更新Activity組件的名稱，newFilters為組件更新后的Intent Filter屬性.基于此，樁組件能夠根據加載目標應用對自身Intent Filter屬性進行熱更新，對相應隱式Intent做出響應.用戶在選擇啟動樁組件(存在多個匹配結果)后，AMS將啟動請求交由目標進程主線程進行處理()，ActivityThreadProxy根據隱式Intent匹配規則()，找出相應目標應用組件，完成組件的啟動工作().

5 實驗與評估

本節將通過實驗對SecureAppV框架的安全性、可用性以及性能進行評估.其中，安全性評估測試框架能否對目標應用存儲和權限進行隔離，定制化代碼在不同沙箱的情況下對目標應用的定制效果；可用性評估測試現實中應用能否在框架內正常運行；性能評估測試應用在框架內運行產生的額外性能開銷.

本文所修改Android版本為android-6.0.1_r77，內核版本3.40，編譯后運行在Nexus 5測試機之上，其處理器為高通驍龍800，2.3GHz主頻，運行內存大小為2G.

5.1 目標應用隔離測試

對于實驗對象的選擇，本文根據下載量在Google Play中選取平行空間等5個具有代表性的虛擬化應用，從Github中下載開源框架VirtualApp和DroidPlugin源碼編譯后，與SecureAppV進行對比.表1為所選虛擬化應用.其中，第一列為所選應用包名，第二列為應用在Google Play中的下載量，第三列為應用申請的系統權限數量.

表1 對比實驗所選虛擬化應用Table 1 Virtualization apps chosen to compare

在本實驗中，本文使用開發的攻擊測試應用分別在上述框架內運行，對框架內目標應用間文件、權限以及系統服務進行隔離測試.

文件隔離測試.在應用虛擬化框架下，目標應用內部文件都保存在框架私有目錄的子目錄內.例如，對于雙開空間(com.ludashi.dualspace)，目標應用內部文件存儲在框架私有目錄/data/data/com.ludashi.dualspace/的子目錄virtual/data/app/target_package_name/下.攻擊應用通過絕對路徑和相對路徑兩種方式嘗試讀取框架內其他應用私有目錄內文件.如果讀取失敗，證明框架進行了文件隔離；讀取成功，則證明框架未對目標應用文件進行隔離.

權限隔離測試.攻擊應用在未對權限INTERNET顯式申請的情況下，進行網絡訪問操作.其中，各個框架均預先申請了INTERNET權限.SecureAppV對測試應用使用默認權限規則，即按照應用清單文件內聲明的權限(未聲明INTERNET權限)進行設置.如果訪問操作成功，證明框架未進行權限隔離，攻擊應用能夠繼承框架申請的權限；操作失敗，則證明框架進行了權限隔離.

服務隔離測試.Android應用通過訪問系統服務可以進行大量敏感操作.為了隔離不同應用數據，服務會對應用身份信息進行驗證.對于系統服務隔離測試，攻擊應用通過訪問系統服務AccountManagerService，嘗試獲取框架內其他應用(Twitter)注冊的賬戶信息.如果訪問成功，證明框架未對系統服務的使用進行隔離；訪問失敗，則證明框架對目標應用使用的系統服務進行了隔離.

表2 隔離實驗測試結果Table 2 Results of security testing experiment

其中“×”表示可以突破安全隔離，“√”表示無法突破隔離，“?”表示現有隔離措施可以被繞過

表2是隔離測試的實驗結果.在文件隔離測試中，只有SecureAppV能夠對目標應用之間文件進行隔離.由于不同應用運行在不同UID之下，由內核目錄訪問控制實現的隔離無法被繞過.對于平行空間，攻擊應用使用絕對路徑和相對路徑均無法對其他應用私有目錄下文件進行訪問.我們對其進行人工分析后發現，平行空間對應用訪問的文件路徑進行了判斷，當路徑前綴指向其他應用私有目錄時，框架會禁止文件訪問的操作.我們通過在攻擊應用自身目錄下，創建所要訪問應用私有文件的軟鏈接[19]，使用此鏈接繞過文件路徑訪問的限制.在權限隔離測試中，僅有SecureAppV對攻擊應用權限進行隔離.在其他框架內，攻擊應用在未申請權限INTERNET情況下，通過繼承框架權限成功進行了網絡訪問操作；在服務隔離測試中，除了框架SecureAppV，攻擊應用通過訪問服務AccountManagerService得到框架內Twitter應用注冊的賬戶信息.

5.2 定制化代碼隔離測試

在該實驗中，我們測試SecureAppV框架在定制化代碼隔離的情況下，對目標應用修改的效果.

圖9 目標應用獲得的虛擬位置信息Fig.9 Mock location get by target app

由上文可知，應用通過地理位置服務的本地代理對象訪問此服務.其中，服務提供的getLastKnownLocation()方法能夠使用GPS定位獲取當前所處地理位置信息.定制化代碼通過繼承類ILocationManager.Stub創建服務的代理對象，并重寫此方法以修改應用獲得的地理位置信息.同時，我們增加用戶自定義規則以允許定制化代碼對目標進程內地理位置服務的本地代理對象進行替換.實驗結果如圖9所示.其中，左半圖為目標應用(高德地圖)在測試機中運行獲得的真實地理位置(上海)，右半圖為應用運行在框架內獲得的虛擬位置信息(紐約).

5.3 可用性測試

對于實驗對象的選擇，本文按照應用分類，從購物、新聞、旅游、社交、音樂、出行、辦公、游戲分類下，各自挑選了一個流行應用進行測試.

表3 應用運行測試結果Table 3 Results of application running

在該實驗中，我們將所選的8個應用運行在SecureAppV框架內，并使用自動化測試工具Monkey[20]，對每個待測應用發出1000個用戶交互事件，記錄應用運行情況.表格3為測試結果.結果顯示，實驗所選應用均能在框架內正常運行，并且運行時未出現應用崩潰的異常情況.

5.4 性能測試

本實驗主要測試應用在SecureAppV框架內運行造成的性能損耗.本文選擇安兔兔、魯大師、Geekbench以及PassMark作為基準測試應用.我們將這些基準測試應用在測試機Nexus5和SecureAppV內分別運行10次，得出每個基準測試應用性能得分的平均值，計算性能損失的百分比.

表4 性能測試結果(10次)Table 4 Results of overhead test(10 times)

表4為性能測試結果.其中，基準測試應用安兔兔運行10次后，在測試機中性能得分平均值(ScoreNexus5)為49562，在框架SecureAppV中得分平均值(ScoreSecureAppV)為48010，降低了1552.我們使用公式，性能損耗=(ScoreNexus5-ScoreSecureAppV)/ScoreNexus5計算得出SecureAppV帶來了3.13%的性能損耗.在剩余3個測試中，SecureAppV分別造成了4.35%、5.02%和11.16%的性能損失，其總體平均值為5.92%.實驗結果表明，SecureAppV帶來較低的性能損失.

6 總 結

本文設計并實現了一個安全隔離的應用虛擬化框架SecureAppV，該框架能夠在滿足虛擬化使用場景的前提下，對目標應用存儲和權限進行隔離.此外，框架對現有虛擬化方案進行了完善.實驗結果表明，SecureAppV在保證安全性的同時，具有較高的可用性，僅造成5.92%的性能損失.