羅 喧，梁柏青，潘軍彪，黃 粵

（中國(guó)電信股份有限公司廣東研究院 廣州510630）

1 引言

隨著移動(dòng)互聯(lián)網(wǎng)的異軍突起，用戶人數(shù)迅猛增長(zhǎng)，作為移動(dòng)互聯(lián)網(wǎng)的訪問入口，智能手機(jī)得到了極大的發(fā)展，出貨量呈現(xiàn)井噴式增長(zhǎng)，根據(jù)IHS iSuppli公司的研究分析，2012年我國(guó)手機(jī)供應(yīng)商的智能手機(jī)出貨量預(yù)計(jì)達(dá)到1.014億部，比2011年的5 200萬部勁增94%，幾乎是2009年1 020萬部的10倍。智能手機(jī)正在成為人們身邊最不可或缺的設(shè)備，是人們與外部世界聯(lián)系的入口，與工作、社交、娛樂、生活息息相關(guān)。

然而，在人們利用智能手機(jī)享受移動(dòng)互聯(lián)新生活時(shí)，智能手機(jī)的安全卻遭遇前所未有的挑戰(zhàn)。《網(wǎng)秦2012年智能手機(jī)安全報(bào)告》顯示，2012年上半年累計(jì)查殺的手機(jī)惡意軟件有17 676款，直接感染手機(jī)1 283萬部，比2011年同期增長(zhǎng)177%。金山網(wǎng)絡(luò)、TechWeb以及機(jī)鋒網(wǎng)聯(lián)合發(fā)布的《2011-2012年度智能手機(jī)安全報(bào)告》的數(shù)據(jù)顯示，2011年智能手機(jī)安全威脅急速上升，日均新增手機(jī)病毒數(shù)量翻10倍，病毒相關(guān)產(chǎn)業(yè)獲利超過3.6億元，超過600萬名用戶通過軟件市場(chǎng)、論壇等渠道中毒。智能手機(jī)的安全問題愈演愈烈，正在成為懸掛在人們頭頂?shù)睦?，成為移?dòng)互聯(lián)網(wǎng)發(fā)展的最大制約因素之一。

業(yè)界定義的智能手機(jī)是一種底層硬件、核心操作系統(tǒng)以及上層多樣化應(yīng)用無縫集成的一體化產(chǎn)品。智能手機(jī)應(yīng)用商城中的應(yīng)用軟件數(shù)以億計(jì)，其軟件安全問題的根本在于移動(dòng)操作系統(tǒng)有若干技術(shù)問題，其對(duì)建立安全的智能手機(jī)應(yīng)用環(huán)境起著關(guān)鍵的作用。其中操作系統(tǒng)提供的應(yīng)用沙盒（sandbox）技術(shù)是智能手機(jī)應(yīng)用安全的基礎(chǔ)軟件生存環(huán)境，提供了應(yīng)用隔離的機(jī)制與資源權(quán)限訪問的模式；其次，應(yīng)用運(yùn)行時(shí)權(quán)限回收技術(shù)為用戶提供了任意時(shí)候的權(quán)限吊銷管理；再次，智能手機(jī)上的組件安全技術(shù)是解決如何攔截惡意軟件利用組件間的通信進(jìn)行非法獲取權(quán)限的惡意行為的方法；最后，敏感信息的流向跟蹤技術(shù)，用來研究如何攔截敏感信息被惡意應(yīng)用非法竊取傳輸?shù)骄W(wǎng)絡(luò)。

2 移動(dòng)終端操作系統(tǒng)的應(yīng)用安全機(jī)制

2.1 沙盒技術(shù)概述

在計(jì)算機(jī)安全中，沙盒是一種將運(yùn)行中的應(yīng)用隔離在有限的范圍內(nèi)，防止應(yīng)用破壞系統(tǒng)以及影響其他應(yīng)用運(yùn)行的機(jī)制?，F(xiàn)代移動(dòng)終端能運(yùn)行大量的第三方來源應(yīng)用軟件，第三方的應(yīng)用軟件很可能夾雜著危害系統(tǒng)及其他應(yīng)用的行為。因此，移動(dòng)終端的操作系統(tǒng)均使用某種沙盒技術(shù)對(duì)應(yīng)用運(yùn)行環(huán)境隔離，使應(yīng)用運(yùn)行在沙盒中，能且僅能訪問應(yīng)用需要的數(shù)據(jù)和系統(tǒng)資源，降低了應(yīng)用破壞系統(tǒng)和數(shù)據(jù)的可能性。沙盒技術(shù)是整個(gè)移動(dòng)終端應(yīng)用安全的基礎(chǔ)。對(duì)應(yīng)用而言，沙盒定義了一組系統(tǒng)對(duì)象集合，并由系統(tǒng)限制應(yīng)用能且僅能訪問定義的對(duì)象。

操作系統(tǒng)的安全訪問控制的模型通常表述為一個(gè)主體（subject）可以訪問哪些對(duì)象（object）。主體是指可以授予或拒絕訪問某個(gè)對(duì)象的人或事物，如用戶、程序、系統(tǒng)進(jìn)程；對(duì)象通常是指被訪問的某種系統(tǒng)的資源，如文件、打印機(jī)等。目前操作系統(tǒng)安全隔離技術(shù)包括自主訪問控制（discretionary access control，DAC） 和 強(qiáng) 制 訪 問 控 制（mandatory access control，MAC）兩種類別，后者是安全的操作系統(tǒng)必須的選擇。

DAC被定義為“一種基于主體的身份或者主體所屬的組別來限制對(duì)象的訪問權(quán)限”，DAC的主要技術(shù)特征是主體所具有的訪問權(quán)限能夠通過繼承或者賦予被傳遞給另外一個(gè)主體，這意味著訪問權(quán)限具有傳遞鏈條，因此，當(dāng)一個(gè)程序中發(fā)生安全裂縫時(shí)，便會(huì)危及系統(tǒng)，這使得DAC在木馬前特別脆弱。目前，最著名的DAC實(shí)現(xiàn)是基于用戶ID和組（group）的UNIX/Linux文件系統(tǒng)的權(quán)限系統(tǒng)。

舉例來說，Linux的文件系統(tǒng)中，某個(gè)用戶A擁有file1的文件，對(duì)file1擁有讀寫權(quán)限，對(duì)其他用戶關(guān)閉了讀寫權(quán)限。一個(gè)惡意攻擊者用戶C，寫了一個(gè)程序，這個(gè)程序在執(zhí)行時(shí)生成文件file2，程序中設(shè)置新的訪問列表：用戶A對(duì)file2的寫權(quán)限和用戶C對(duì)file2的讀權(quán)限。用戶C把惡意程序偽裝成合法程序發(fā)給用戶A，當(dāng)程序被A運(yùn)行時(shí)，程序具有了A的訪問權(quán)限，程序邏輯中拷貝file1到file2，于是用戶C竊取了file1的內(nèi)容。如果用戶A是系統(tǒng)管理員，攻擊者C會(huì)獲取最大的權(quán)限。

與此對(duì)比，在MAC模型里，由管理員制定策略，策略定義了哪個(gè)主體能訪問哪個(gè)對(duì)象。MAC對(duì)所有主體及其所控制的客體（如文件、設(shè)備、系統(tǒng)資源）實(shí)施強(qiáng)制訪問控制，為這些主體及客體指定敏感標(biāo)記，作為實(shí)施強(qiáng)制訪問控制的依據(jù)。系統(tǒng)通過比較主體和客體的敏感標(biāo)記來決定一個(gè)主體是否能夠訪問某個(gè)客體。如果沒有被管理員顯式授權(quán)，用程序自身不能改變它自己及任何其他主體、客體的敏感標(biāo)記，從而增加了安全的防備。

MAC的實(shí)現(xiàn)中，有多種對(duì)象標(biāo)記和策略判斷規(guī)則，不同的MAC系統(tǒng)實(shí)現(xiàn)并不一樣。

在目前兩種主流的操作系統(tǒng)iOS和Android的應(yīng)用沙盒技術(shù)中，均采用了某種程度的MAC的技術(shù)實(shí)現(xiàn)。前者在操作系統(tǒng)內(nèi)核層面實(shí)現(xiàn)了MAC，而后者在中間層實(shí)現(xiàn)了MAC。

2.2 iOS的應(yīng)用沙盒

蘋果公司的iOS的應(yīng)用沙盒，是一種強(qiáng)限制的結(jié)構(gòu)，根據(jù)蘋果公司的開發(fā)文檔描述，iOS的應(yīng)用沙盒將應(yīng)用限制的級(jí)別定義為“每一個(gè)應(yīng)用都是一個(gè)孤島”。為了軟件安全，這種設(shè)計(jì)極大程度地推崇應(yīng)用隔離，犧牲了本機(jī)內(nèi)應(yīng)用間的信息共享。

圖1示意的iOS應(yīng)用沙盒來自蘋果公司的官方文檔。

應(yīng)用“孤島”是如何形成的呢？蘋果公司的iOS的應(yīng)用沙盒提供細(xì)粒度的應(yīng)用權(quán)限訪問控制。其應(yīng)用沙盒的主要訪問限制可以總結(jié)如下：

·應(yīng)用只看到沙盒容器目錄，下面表述為，不可見系統(tǒng)的其他目錄和整個(gè)文件系統(tǒng)，沙箱中關(guān)鍵子目錄，如/AppName.app、/Documents/、/Documents/Inbox、/Library/等，每個(gè)子目錄的使用方法有嚴(yán)格規(guī)定；

·/Documents/Inbox只有讀和刪除的權(quán)限，沒有寫的權(quán)限；

圖1 iOS的應(yīng)用沙盒

·應(yīng)用可以對(duì)用戶的照片、視頻內(nèi)容及iTunes目錄進(jìn)行只讀訪問；

·應(yīng)用可以對(duì)用戶的聯(lián)系人數(shù)據(jù)（Sqlite本地文件數(shù)據(jù)庫(kù)）進(jìn)行讀、寫訪問；

·應(yīng)用可以啟動(dòng)網(wǎng)絡(luò)連接發(fā)送和接收數(shù)據(jù)；

·應(yīng)用僅通過系統(tǒng)API和服務(wù)的控制執(zhí)行有限制類型的后臺(tái)服務(wù)；

·應(yīng)用不可以連接本地的UNIX網(wǎng)絡(luò)連接字服務(wù)；

·應(yīng)用不可以讀取系統(tǒng)的日志目錄；

·不在權(quán)限列表中描述的操作均不能通過授權(quán)等。

iOS的應(yīng)用沙盒并不是一種基于UNIX用戶ID的權(quán)限控制DAC方案，而是操作系統(tǒng)內(nèi)核層次的MAC的實(shí)現(xiàn)，操作系統(tǒng)集成了TrustedBSD MAC Framework項(xiàng)目，實(shí)現(xiàn)應(yīng)用沙盒。

iOS的應(yīng)用沙盒執(zhí)行結(jié)果，可以參照iOS操作系統(tǒng)的同源操作系統(tǒng)MAC OS X的sandbox-exec命令來觀察，在MAC OS X中，存在著使用沙盒機(jī)制運(yùn)行應(yīng)用的命令：

sandbox-exec[-f profile-file][-n profile-name][-p profilestring][-D key=value...]command[arguments...]

如果在一個(gè)沒有Internet訪問權(quán)限的沙盒中運(yùn)行ping命令，將直接返回權(quán)限不足夠。

$ sandbox-exec-n no-internet ping www.google.com

PING www.l.google.com(209.85.148.106):56 data bytes

ping:sendto:Operation not permitted

iOS/MAC OS X對(duì)不同的應(yīng)用類型，定義了不同的沙盒。沙盒的訪問權(quán)限定義配置文件可以使用SBPL(sandbox policy language)，以正則表達(dá)式的語法來描述。在應(yīng)用啟動(dòng)的同時(shí)沙盒啟動(dòng)，沙盒的配置被傳遞到操作系統(tǒng)內(nèi)核執(zhí)行。

iOS應(yīng)用沙盒的強(qiáng)大之處不僅在于單純的技術(shù)實(shí)現(xiàn)，還在于蘋果公司強(qiáng)大的運(yùn)營(yíng)能力。應(yīng)用在發(fā)布到蘋果的應(yīng)用商店之前，經(jīng)過蘋果公司嚴(yán)格的審核測(cè)試，如果應(yīng)用不遵循沙盒的設(shè)計(jì)規(guī)格，將不能正常運(yùn)作，或者在審核環(huán)節(jié)被廢棄，即使在上市之后如果被發(fā)現(xiàn)有惡意的行為仍然會(huì)被下架。

2.3 Android的應(yīng)用沙盒

Android操作系統(tǒng)的沙盒技術(shù)，是基于Linux的原生進(jìn)程與用戶賬號(hào)組合進(jìn)行限制的功能。Android是一種多用戶的Linux操作系統(tǒng)，每個(gè)應(yīng)用使用不同的用戶ID運(yùn)行進(jìn)程，并對(duì)應(yīng)用的數(shù)據(jù)文件進(jìn)行Linux操作層次的文件訪問保護(hù)，賦予且僅賦予程序用戶的ID以訪問權(quán)限，使用其他用戶ID運(yùn)行的程序無法越權(quán)訪問程序所保護(hù)的數(shù)據(jù)。

與此相關(guān)的另一個(gè)技術(shù)特點(diǎn)是：Android應(yīng)用簽名不需要權(quán)威的中心進(jìn)行認(rèn)證，其驗(yàn)證簽名僅是為了區(qū)分應(yīng)用的提供商身份，相同應(yīng)用提供商簽名的多個(gè)應(yīng)用可以運(yùn)行在同一個(gè)進(jìn)程空間，彼此更緊密耦合地共享數(shù)據(jù)訪問。

操作系統(tǒng)層面基于Linux用戶ID的權(quán)限控制是一種DAC的權(quán)限控制，DAC的缺點(diǎn)如2.1節(jié)所述，是系統(tǒng)在面對(duì)特洛伊木馬惡意程序時(shí)表現(xiàn)的脆弱。為了保持Linux內(nèi)核的相對(duì)獨(dú)立性，Android在Linux之上的中間層添加了MAC式的權(quán)限控制——permission機(jī)制，根據(jù)應(yīng)用安裝時(shí)用戶的授權(quán)權(quán)限定義進(jìn)行敏感數(shù)據(jù)和操作許可的判斷。下面闡述的是Android的permission機(jī)制。

Android對(duì)系統(tǒng)中的各種資源訪問能力定義了詳細(xì)的權(quán)限要求列表，例如，讀取聯(lián)系人的權(quán)限為read_contacts，發(fā)送短信的權(quán)限為send_sms，訪問攝像頭的權(quán)限為camera等。在用戶下載安裝應(yīng)用的時(shí)候，應(yīng)用列出所需的軟件授權(quán)權(quán)限列表，用戶必須同意給予授權(quán)，才能繼續(xù)安裝應(yīng)用。應(yīng)用安裝成功后，針對(duì)限制應(yīng)用的沙盒生成，該沙盒限制應(yīng)用只能訪問用戶授權(quán)的能力訪問范圍。某種Android手機(jī)上，通過設(shè)置→應(yīng)用程序→管理應(yīng)用程序→應(yīng)用程序信息→權(quán)限菜單進(jìn)入查看應(yīng)用的權(quán)限信息，看到的權(quán)限列表如圖2所示。

2.4 沙盒技術(shù)困境

移動(dòng)手機(jī)上沙盒技術(shù)一個(gè)困擾的問題是：應(yīng)用的授權(quán)是否應(yīng)該由用戶負(fù)責(zé)，用戶是移動(dòng)手機(jī)和其數(shù)據(jù)的所有者，卻不是專業(yè)的超級(jí)管理員。Android的應(yīng)用需要用戶對(duì)應(yīng)用進(jìn)行授權(quán)，很大一部分用戶可能不具備專業(yè)的技術(shù)背景理解每個(gè)權(quán)限代表的含義，因此無法做技術(shù)判斷。例如，當(dāng)安裝應(yīng)用向用戶請(qǐng)求讀取聯(lián)系人（read_contacts）以及訪問網(wǎng)絡(luò)的權(quán)限時(shí)，應(yīng)用可能將聯(lián)系人的信息發(fā)往網(wǎng)絡(luò)，然而用戶很可能不了解其中聯(lián)系人隱私泄漏的風(fēng)險(xiǎn)。

與此相比，在iOS的實(shí)現(xiàn)中，通過平臺(tái)運(yùn)營(yíng)來彌補(bǔ)用戶技術(shù)背景上的缺陷，在蘋果公司的應(yīng)用商店發(fā)布應(yīng)用之前，必須經(jīng)過蘋果公司嚴(yán)格的審核，如靜態(tài)代碼分析、動(dòng)態(tài)代碼分析，保證應(yīng)用沒有侵害用戶權(quán)益的惡意行為。另外，Android的應(yīng)用簽名沒有經(jīng)過權(quán)威認(rèn)證，當(dāng)用戶發(fā)現(xiàn)應(yīng)用有惡意行為的時(shí)候，可能會(huì)找不到實(shí)施惡意行為的軟件公司或者個(gè)人。蘋果公司發(fā)現(xiàn)應(yīng)用的惡意行為則可以直接將應(yīng)用從蘋果的應(yīng)用商店下架。

圖2 某種Android手機(jī)上的權(quán)限列表

3 應(yīng)用運(yùn)行時(shí)動(dòng)態(tài)授權(quán)控制

應(yīng)用運(yùn)行時(shí)動(dòng)態(tài)授權(quán)控制技術(shù)是指用戶能夠在應(yīng)用安裝后，修改應(yīng)用對(duì)智能手機(jī)終端敏感能力的訪問授權(quán)，在一些技術(shù)文檔中，該功能被描述為權(quán)限吊銷或者權(quán)限回收（permission revocation）。這種技術(shù)主要針對(duì)目前的智能手機(jī)終端中的軟件授權(quán)不能在應(yīng)用安裝后收回敏感能力訪問授權(quán)的問題。如2.3節(jié)所述，Android用戶在安裝時(shí)必須全盤接受應(yīng)用要求的權(quán)限列表，用戶在安裝后不能收回應(yīng)用授權(quán)，若發(fā)現(xiàn)軟件有惡意的行為只能卸載該軟件。

然而在用戶使用應(yīng)用過程中，用戶具有收回部分應(yīng)用授權(quán)的強(qiáng)烈需求。例如，用戶在使用某個(gè)微博應(yīng)用的時(shí)候，發(fā)現(xiàn)該微博應(yīng)用訪問了照片信息，用戶對(duì)此行為并不認(rèn)同，于是，用戶需要收回對(duì)照片目錄的訪問權(quán)限，但不影響微博應(yīng)用的基本使用，僅限制了需要訪問照片目錄的功能。

如上文所述，iOS和Android的沙盒均是某種MAC技術(shù)，前者是操作系統(tǒng)層面實(shí)現(xiàn)的MAC技術(shù)，后者是操作系統(tǒng)之上的中間層實(shí)現(xiàn)的MAC技術(shù)。此處的討論焦點(diǎn)在于，這兩種MAC沙盒能否支持動(dòng)態(tài)的權(quán)限定義修改？在MAC控制模式中，應(yīng)用不能自行繁殖或者修改授權(quán)的策略定義，當(dāng)系統(tǒng)發(fā)現(xiàn)當(dāng)前應(yīng)用需要某項(xiàng)授權(quán)來運(yùn)作某種功能時(shí)，由系統(tǒng)服務(wù)彈出窗口與用戶直接交互獲取用戶的授權(quán)，或者引導(dǎo)用戶到配置窗口進(jìn)行授權(quán)，亦即需要直接獲取用戶的真實(shí)操作意圖。

3.1 iOS的應(yīng)用運(yùn)行時(shí)動(dòng)態(tài)授權(quán)控制

蘋果公司的iPhone設(shè)備升級(jí)到iOS 6，具有部分敏感能力的動(dòng)態(tài)權(quán)限授權(quán)控制功能，包括系統(tǒng)的敏感數(shù)據(jù)或者能力，如GPS能力、通訊錄訪問、日歷、提醒事項(xiàng)、照片、藍(lán)牙共享，甚至是關(guān)鍵的社交應(yīng)用，如Twitter、Facebook、新浪微博的賬戶等。在iOS 6的“設(shè)置—隱私”窗口中選擇通訊錄，可以看到請(qǐng)求訪問通訊錄信息的所有應(yīng)用，用戶具有可以選擇關(guān)閉某個(gè)應(yīng)用訪問通訊錄的能力。如圖3所示，倘若用戶關(guān)閉了微信的QQ通訊錄的訪問權(quán)限，僅影響微信中與通訊錄相關(guān)的功能，并不影響微信其他功能的正常訪問。此功能說明iOS 6的沙盒功能具有動(dòng)態(tài)調(diào)整權(quán)限定義的能力。

圖3 iOS 6的動(dòng)態(tài)權(quán)限授權(quán)控制

3.2 Android的應(yīng)用運(yùn)行時(shí)動(dòng)態(tài)授權(quán)控制

對(duì)Android操作系統(tǒng)來說，官方提供的版本并不提供動(dòng)態(tài)的應(yīng)用訪問授權(quán)修改功能。一些基于Android Open Source Project開源社區(qū)提供的包含了整個(gè)操作系統(tǒng)的鏡像的計(jì)算機(jī)數(shù)據(jù)文件，用于向手機(jī)的ROM（read-only memory）芯片刷寫安裝系統(tǒng)的第三方ROM或者某些應(yīng)用，提供此功能，下面介紹幾種實(shí)現(xiàn)方案。

第1種是需要修改系統(tǒng)的本身，對(duì)系統(tǒng)進(jìn)行打補(bǔ)丁或者修改其權(quán)限機(jī)制。例如著名的Android非官方發(fā)布版本CyanogenMod在7.0的時(shí)候提供了應(yīng)用授權(quán)回收的功能，在一臺(tái)刷了CyanogenMod提供ROM的手機(jī)中，動(dòng)態(tài)地管理應(yīng)用程序的權(quán)限；SeAndroid的開源項(xiàng)目，將權(quán)限吊銷列入其MAC沙盒機(jī)制的實(shí)現(xiàn)范圍，一些安全應(yīng)用提供Android內(nèi)核補(bǔ)丁加上一個(gè)用于管理的外部應(yīng)用。這類權(quán)限回收方案的實(shí)現(xiàn)需要重新刷機(jī)，對(duì)普通用戶而言無疑是個(gè)無法駕馭的方案。

第2種方案是需要對(duì)手機(jī)終端進(jìn)行“root”。“root”是指破解移動(dòng)設(shè)備，使之運(yùn)行在超級(jí)用戶權(quán)限下。從原理上說，權(quán)限回收功能僅能由系統(tǒng)提供，此功能的運(yùn)作勢(shì)必需要最高的超級(jí)用戶權(quán)限，不可避免地需要將終端設(shè)備進(jìn)行“root”。此方案破解了移動(dòng)設(shè)備，為用戶帶來了其他的安全問題。

第3種方案其實(shí)是一種取巧的方案。取消權(quán)限的時(shí)候，需要用戶主動(dòng)卸載原來的應(yīng)用，重新生成權(quán)限定義的AndroidManifest.xml文件，然后用戶再安裝新打包的應(yīng)用。這種實(shí)現(xiàn)方案的問題是：有些預(yù)裝的應(yīng)用無法卸載，另外，修改了軟件的官方發(fā)布的打包。

目前來看，Android上應(yīng)用訪問權(quán)限回收的功能并不成熟。

4 智能手機(jī)的組件跨進(jìn)程安全研究

在移動(dòng)終端的實(shí)現(xiàn)中，存在著跨應(yīng)用進(jìn)程協(xié)作，例如，在查看用戶最近郵件的功能中，可能需要啟動(dòng)聯(lián)系人查看功能。由于郵件客戶端功能和聯(lián)系人功能分屬兩個(gè)不同的應(yīng)用，此類功能存在著應(yīng)用間的跨進(jìn)程協(xié)作。

應(yīng)用沙盒技術(shù)和應(yīng)用間的通信是互相矛盾的，應(yīng)用沙盒技術(shù)能夠?qū)⒁苿?dòng)應(yīng)用對(duì)系統(tǒng)資源的訪問限制在有限的資源集合內(nèi)；而應(yīng)用間通信則存在可能繞過應(yīng)用沙盒，通過其他的應(yīng)用間接獲取對(duì)系統(tǒng)資源的使用。因此，應(yīng)用間的通信需要被安全模型所監(jiān)管。

4.1 iOS的應(yīng)用跨進(jìn)程協(xié)作

蘋果公司的iOS的應(yīng)用沙盒依靠應(yīng)用間通信的強(qiáng)力管制來實(shí)現(xiàn)，應(yīng)用之間不直接進(jìn)行通信或者共享數(shù)據(jù)，如果應(yīng)用需要另一個(gè)應(yīng)用的協(xié)作來完成一項(xiàng)任務(wù)，只能通過系統(tǒng)提供的API或者服務(wù)。

舉一個(gè)例子來說，E-mail應(yīng)用和TXT編輯應(yīng)用嚴(yán)格隔離，如果E-mail應(yīng)用需要TXT文本編輯器打開和顯示一個(gè)文本的附件，TXT文本編輯器需要聲明自身能處理的文檔類型，當(dāng)用戶點(diǎn)擊E-mail的附件并選擇了TXT文件編輯器的時(shí)候，E-mail的TXT附件被iOS系統(tǒng)機(jī)制傳送到TXT文本編輯應(yīng)用的/Documents/Inbox目錄下，TXT文本應(yīng)用讀取這個(gè)附件文件并展現(xiàn)給用戶，當(dāng)用戶編輯這個(gè)文本附件時(shí)，TXT文本編輯應(yīng)用應(yīng)將這個(gè)文件移動(dòng)到本應(yīng)用的數(shù)據(jù)目錄下，因?yàn)樯澈幸?guī)定/Documents/Inbox只有讀取和刪除文件的權(quán)限，并沒有寫文件的權(quán)限。這是嚴(yán)格的沙盒結(jié)構(gòu)的特例流程，蘋果公司官方開發(fā)文檔中需要專門文檔進(jìn)行闡述。

iOS的設(shè)計(jì)為應(yīng)用的跨進(jìn)程協(xié)作設(shè)置了非常高的技術(shù)門檻，基本上杜絕了應(yīng)用間互相勾結(jié)和利用其他應(yīng)用提供的接口進(jìn)行非法行為的可能性。

4.2 Android的應(yīng)用跨進(jìn)程協(xié)作

4.2.1 Android的應(yīng)用組件及技術(shù)特點(diǎn)

4.2.1 .1 Android的應(yīng)用組件構(gòu)成

對(duì)Android操作系統(tǒng)來說，應(yīng)用的跨進(jìn)程協(xié)作無處不在。Android操作系統(tǒng)上最小的可管理重用的協(xié)作單元是組件。應(yīng)用、進(jìn)程、組件之間的關(guān)系如圖4所示。

圖4 應(yīng)用、進(jìn)程、組件的關(guān)系

Activity組件是包含顯示窗口的基本的Android程序組件，是人機(jī)交互的基本單元。Activity組件具有運(yùn)行時(shí)的上下文和獨(dú)特的生命周期，系統(tǒng)根據(jù)需要進(jìn)行Activity組件調(diào)度。Activity組件可以由用戶點(diǎn)擊系統(tǒng)桌面圖標(biāo)或者經(jīng)由其他應(yīng)用啟動(dòng)。

Service組件不包含人機(jī)交互的界面，在后臺(tái)執(zhí)行某長(zhǎng)期工作任務(wù)的組件，可以由應(yīng)用內(nèi)部的其他組件啟動(dòng)。Service組件的另一用法是提供綁定IPC（進(jìn)程間通信）的接口，支持實(shí)現(xiàn)遠(yuǎn)程調(diào)用。Service組件支持任意類型的后臺(tái)任務(wù)，包括執(zhí)行網(wǎng)絡(luò)事務(wù)、播放音樂、下載后臺(tái)文件等。

Content Provider組件用于管理應(yīng)用中可共享的數(shù)據(jù)，如文件、數(shù)據(jù)庫(kù)。

Broadcast Receiver組件用于接收系統(tǒng)范圍內(nèi)的事件聲明，例如，屏幕將被關(guān)黑、電池處在低電，或者其他程序的廣播通知等。

Android組件設(shè)計(jì)的關(guān)鍵特點(diǎn)是：程序可以啟動(dòng)另一個(gè)程序的組件。例如，某團(tuán)隊(duì)開發(fā)一個(gè)程序，需要實(shí)現(xiàn)用戶打開攝像頭并抓拍一張照片的流程，此功能已經(jīng)有另一個(gè)應(yīng)用的一系列組件完整實(shí)現(xiàn)，則不需要重新開發(fā)，只需要直接使用現(xiàn)有應(yīng)用的組件即可。所謂的“直接使用”甚至不用將已有應(yīng)用的組件鏈接進(jìn)新的程序。

4.2.1 .2 Android組件通信機(jī)制

Android有3種組件通信機(jī)制：Intent機(jī)制、IPC Binding機(jī)制和Content Resolver。Intent機(jī)制能夠喚起Android的3種組件，Activity、Service、Boardcast Receiver是Android組件間主要的通信方式，是一種間接的通信方式。IPC Binding機(jī)制是使用遠(yuǎn)程函數(shù)調(diào)用的方法與Service組件通信，Content Resolver用于與Content Provider組件通信。

Intent是一種Android組件間的異步事件對(duì)象，攜帶了發(fā)送組件的“操作意圖”。翻譯成自然語言：發(fā)送Intent組件期望某個(gè)具體的組件（顯式指定）或者期望系統(tǒng)幫忙找合適的組件（隱式指定）完成一項(xiàng)具體的任務(wù)，系統(tǒng)找到目標(biāo)組件后，如果其沒有處在運(yùn)行狀態(tài)，則負(fù)責(zé)創(chuàng)建組件并調(diào)度到運(yùn)行狀態(tài)執(zhí)行指定的任務(wù)。Intent機(jī)制保證了Android可以最大限度地重用系統(tǒng)或者其他安裝應(yīng)用的成熟組件。

Service組件能夠支持遠(yuǎn)程函數(shù)調(diào)用接口，這就是IPC的Binding用法，是Service組件與其他組件通信的一種特殊通信方式。

Content Provider組件不能由Intent喚醒，Content Provider僅 與Content Resolver通 信，由 其 喚 醒。Content Resolver處理與Content Provider通信的整個(gè)過程，與Content Provider通信的組件不需要添加額外的邏輯，僅調(diào)用Content Resolver即可。

4.2.2 Android的應(yīng)用組件通信的安全研究

最近，業(yè)界注意到了Android應(yīng)用安全的一個(gè)嚴(yán)重問題，應(yīng)用間存在的勾結(jié)“Collusion”的惡意行為以及應(yīng)用可能利用現(xiàn)有系統(tǒng)或者第三方應(yīng)用的權(quán)限漏洞進(jìn)行“Confused Deputy Attack”的攻擊。

如同上文所述，Android的應(yīng)用組件間能夠互相喚醒和調(diào)用以及存在著其他直接的溝通途徑，組件間溝通通常并不在系統(tǒng)的permission機(jī)制控制范圍內(nèi)，因此具有嚴(yán)重的問題。

如圖5所示，系統(tǒng)應(yīng)用的某Service組件（此處稱為S）定義了訪問者需具有訪問智能手機(jī)終端的地理位置信息access_fine_location權(quán)限方能響應(yīng)請(qǐng)求。應(yīng)用2所在的應(yīng)用沙盒具有access_fine_location的訪問權(quán)限，因此其Service組件S2能夠合法地喚起S組件。若應(yīng)用2由于疏忽或者惡意的動(dòng)機(jī)，沒有對(duì)S2的訪問者進(jìn)行限制定義，實(shí)施惡意行為的應(yīng)用1可以啟動(dòng)后臺(tái)運(yùn)行的Service組件S1，S1將通過應(yīng)用2的S2組件間接發(fā)起對(duì)S組件的調(diào)用，獲取用戶的地理位置隱私信息。

圖5 系統(tǒng)應(yīng)用的某Service組件

此處的惡意攻擊可以分屬兩種類別：第一種是被利用的組件是正常的組件，由于疏于保護(hù)而被惡意軟件所用，這種攻擊被稱為Confused Deputy Attack，據(jù)研究，Android欠缺完善的自我保護(hù)的組件有許多，包括第三方的應(yīng)用以及系統(tǒng)的應(yīng)用，如電話應(yīng)用、音樂應(yīng)用、配置應(yīng)用等。第二種是被利用的組件與實(shí)施惡意行為的組件是有意配合和協(xié)作的關(guān)系，稱為Collusion，比如惡意攻擊者首先發(fā)布一個(gè)功能正常的程序，實(shí)現(xiàn)正常的功能引誘用戶下載，這個(gè)功能正常的程序獲得了用戶的授權(quán)，能夠讀取敏感的數(shù)據(jù)，此程序向特定的應(yīng)用開放了調(diào)用權(quán)限，然后再發(fā)布一個(gè)功能表面正常的程序，引導(dǎo)用戶給予訪問互聯(lián)網(wǎng)或者發(fā)送短信等的授權(quán)。后一個(gè)應(yīng)用調(diào)用前一個(gè)應(yīng)用，則可以完成竊取用戶的隱私數(shù)據(jù)并發(fā)送到互聯(lián)網(wǎng)。應(yīng)該說，這兩種攻擊技術(shù)沒有本質(zhì)的不同。應(yīng)用間可用的“協(xié)作”途徑如下。

·兩個(gè)Android應(yīng)用通過內(nèi)部文件進(jìn)行通信。第一個(gè)應(yīng)用可以將需要通信的內(nèi)容寫到系統(tǒng)的日志中，第二個(gè)應(yīng)用在獲取read_logs權(quán)限之后讀取日志的內(nèi)容。兩個(gè)應(yīng)用完成通信。

·共享屬性，Android操作系統(tǒng)的共享屬性是一種的鍵值對(duì)，Android提供了API進(jìn)行讀寫。第一個(gè)應(yīng)用獲取了mode_world_readavle和mode_world_writable模式允許其他應(yīng)用讀寫其共享屬性。

·組件間的通信機(jī)制，上文所述的Intent機(jī)制，可以讓一個(gè)應(yīng)用間接地喚起另一個(gè)應(yīng)用的Activity、Service、Boardcast Receiver的3種組件，后兩種組件可以運(yùn)行在后臺(tái)，在用戶沒有察覺的情況下運(yùn)行。IPC Binding機(jī)制可以讓一個(gè)應(yīng)用調(diào)用另一個(gè)應(yīng)用的后臺(tái)運(yùn)行的Service組件，甚至一個(gè)應(yīng)用可以共享Content Provider組件，另一個(gè)應(yīng)用則可以直接讀寫Content Provider組件中存儲(chǔ)的信息。

·直接使用本地網(wǎng)絡(luò)套接字服務(wù)等。

“Confused Deputy Attack”和“Collusion”的安全 問題涉及多個(gè)應(yīng)用，應(yīng)用可能來源于同一個(gè)簽名，也可能來源于不同的簽名，應(yīng)用組件只要有一個(gè)組件有問題，就將成為系統(tǒng)的一個(gè)“后門”，可以為其他的惡意應(yīng)用所利用。由于涉及多個(gè)應(yīng)用的協(xié)作，單純掃描、查詢和分析某一個(gè)應(yīng)用的行為，可能無法發(fā)現(xiàn)此類問題的所在。

為了解決Android平臺(tái)上利用組件間通信實(shí)施的惡意行為，目前業(yè)界和學(xué)術(shù)界對(duì)Android平臺(tái)提出了不少改進(jìn)和擴(kuò)展方案，這些研究方案均在發(fā)展中，并未合并進(jìn)主流的Android版本。

例如，其中一種典型的方案是，若組件A具有權(quán)限訪問組件B，組件B具有權(quán)限訪問組件C，記錄一條路徑，標(biāo)記組件A對(duì)組件C具有訪問權(quán)限。以此類推，進(jìn)行分析，對(duì)Android平臺(tái)的所有組件之間保存一張表，描述每個(gè)組件的通達(dá)路徑。將此表交付給用戶審核，去除用戶不認(rèn)同的訪問路徑之后，由方案擴(kuò)展的Android組件強(qiáng)制執(zhí)行。此實(shí)現(xiàn)方法對(duì)用戶的要求更高，用戶通常并無知識(shí)背景讀懂復(fù)雜的組件權(quán)限訪問路徑表，因此，此方案不能算是成功的方案。

5 敏感信息的流向跟蹤技術(shù)

5.1 實(shí)現(xiàn)的基本原理

移動(dòng)互聯(lián)網(wǎng)應(yīng)用中，用戶的隱私信息，如聯(lián)系人、地理位置、電話號(hào)碼、通話記錄等信息都很容易被應(yīng)用竊取，并上傳到某個(gè)網(wǎng)絡(luò)服務(wù)器上。目前一般的技術(shù)手段無法解決這個(gè)問題。例如，對(duì)于Android的平臺(tái)，如果應(yīng)用要求有訪問聯(lián)系人的權(quán)限以及訪問互聯(lián)網(wǎng)的權(quán)限，應(yīng)用就有可能將聯(lián)系人的信息上傳到互聯(lián)網(wǎng)。

為了更徹底地解決這個(gè)問題，學(xué)術(shù)界出現(xiàn)了利用移動(dòng)終端上的敏感信息進(jìn)行流向跟蹤的技術(shù)。目前，主要有TaintDroid開源項(xiàng)目、SeAndroid的開源項(xiàng)目等。下面以TaintDroid項(xiàng)目為例，介紹移動(dòng)手機(jī)上的敏感信息流向跟蹤技術(shù)。

TaintDroid的基本思路是：通過改造Android上的Dalvik虛擬機(jī)（Android上的Java虛擬機(jī)實(shí)現(xiàn)），使之對(duì)包含了敏感信息的變量進(jìn)行標(biāo)記。例如，如果變量數(shù)據(jù)的原始來源是用戶的聯(lián)系人、郵件、日程等敏感信息，變量是被敏感信息“污染”的，在被“污染”的變量上設(shè)置敏感信息標(biāo)記。當(dāng)變量被復(fù)制時(shí)，敏感標(biāo)記同樣進(jìn)行了繁殖，如果包含了敏感信息的變量被作為參數(shù)發(fā)送出系統(tǒng)外，則向用戶告警，如果用戶不允許此操作，則進(jìn)行攔截。

TaintDroid修改Dalvik虛擬機(jī)的實(shí)現(xiàn)，對(duì)基礎(chǔ)的函數(shù)局部變量、函數(shù)參數(shù)、類靜態(tài)變量、類實(shí)例變量、數(shù)組變量等，添加額外的標(biāo)記數(shù)據(jù)位，標(biāo)記存儲(chǔ)變量是否為敏感信息；對(duì)函數(shù)局部變量、函數(shù)參數(shù)需修改原本函數(shù)的壓棧結(jié)構(gòu)，為每個(gè)變量添加額外的標(biāo)記位；對(duì)類的靜態(tài)變量、類實(shí)例變量需要修改類的實(shí)現(xiàn)添加額外的標(biāo)記位。數(shù)組變量則是整個(gè)數(shù)組共享一個(gè)敏感信息標(biāo)記位，即當(dāng)數(shù)組變量有部分?jǐn)?shù)據(jù)為敏感數(shù)據(jù)時(shí)，整個(gè)數(shù)組變量為敏感的數(shù)據(jù)。

對(duì)Dalvik虛擬機(jī)運(yùn)作的DEX機(jī)制指令集的每個(gè)指令，TaintDroid添加敏感標(biāo)記位的繁殖邏輯，當(dāng)發(fā)現(xiàn)敏感信息的變量、對(duì)象、常量等被復(fù)制和運(yùn)算時(shí)，按照繁殖的規(guī)則，敏感信息標(biāo)記位繁殖復(fù)制到運(yùn)算涉及的其他變量。

圖6 TaintDroid的敏感標(biāo)記位繁殖邏輯

例如，a=b語句，機(jī)器運(yùn)算指令為move-op a b，變量b如果為包含敏感信息的變量，本語句運(yùn)算完成后，a變量也將被設(shè)置為敏感信息的標(biāo)記位。其實(shí)際意義在于，如果變量b包含敏感信息，如用戶的銀行賬號(hào)，即b是被敏感信息“污染”的變量，因此，在程序的運(yùn)算過程中，如果b被賦值給另外的變量a，那么a也是被敏感信息“污染”的變量。

圖6是TaintDroid的敏感標(biāo)記位繁殖邏輯示意[4]，其中vx為寄存器變量，包括函數(shù)局部變量、參數(shù)變量；fx為類的靜態(tài)變量，類的實(shí)例變量表示為vyfx，其中的vy為實(shí)例對(duì)象引用；R為返回變量，E為異常變量（exception），C為常量；vx[.]為數(shù)組的變量。

5.2 實(shí)現(xiàn)的技術(shù)瓶頸

敏感信息流向的跟蹤技術(shù)是一種復(fù)雜而尚待檢驗(yàn)的技術(shù)，在這種技術(shù)實(shí)現(xiàn)中，有一些尚待檢驗(yàn)和有待成熟的技術(shù)瓶頸問題。

（1）敏感信息標(biāo)記繁殖規(guī)則的準(zhǔn)確性問題

變量敏感信息標(biāo)記如果在程序運(yùn)算的過程中不能被準(zhǔn)確地繁殖，用戶的隱私就很可能被泄漏。

（2）遠(yuǎn)程調(diào)用過程中的敏感信息標(biāo)記位的傳遞

Dalvik虛擬機(jī)的遠(yuǎn)程調(diào)用使用的是Binder IPC技術(shù)，需要修改Android的Binder服務(wù)類庫(kù)來攜帶進(jìn)程遠(yuǎn)程調(diào)用中的敏感標(biāo)記信息。

（3）在本地調(diào)用（native call和JNI）的敏感信息中傳遞

由于無法跟蹤Dalvik虛擬機(jī)之外的本地方法調(diào)用過程中的敏感標(biāo)記繁殖，為了保證敏感信息不外泄，有兩種方法：第一種方法認(rèn)為所有訪問本地方法調(diào)用的變量均是被“污染”的，需要添加標(biāo)記，這無疑粗放地?cái)U(kuò)大了“污染”的范圍；第二種方法對(duì)本地系統(tǒng)方法調(diào)用的函數(shù)進(jìn)行辨別，這種辨別需要對(duì)系統(tǒng)調(diào)用的每個(gè)函數(shù)進(jìn)行分析，這種工作難度比較大，并需要在系統(tǒng)每個(gè)版本更新的時(shí)候，更新系統(tǒng)函數(shù)調(diào)用的分析庫(kù)。

（4）在文件系統(tǒng)以及外部存儲(chǔ)過程的敏感信息傳遞

敏感信息的變量可能被存儲(chǔ)到文件系統(tǒng)（Android上的文件系統(tǒng)是YAFFS2）和設(shè)備的SD卡存儲(chǔ)系統(tǒng)（如ext 2）時(shí)丟失敏感標(biāo)記，為了避免這種情況，需要擴(kuò)展文件系統(tǒng)的屬性，保持敏感信息標(biāo)記，這是待深化研究的領(lǐng)域。

6 結(jié)束語

隨著移動(dòng)互聯(lián)網(wǎng)的迅猛發(fā)展，從各大安全公司以及研究機(jī)構(gòu)最近發(fā)布的智能手機(jī)安全報(bào)告來看，智能手機(jī)的安全問題愈演愈烈，正在成為制約移動(dòng)互聯(lián)網(wǎng)發(fā)展的關(guān)鍵瓶頸之一。從本文的研究發(fā)現(xiàn)，應(yīng)用安全的關(guān)鍵技術(shù)均嚴(yán)重依賴于移動(dòng)操作系統(tǒng)提供的平臺(tái)基礎(chǔ)，如沙盒隔離機(jī)制、應(yīng)用組件構(gòu)成等。因此，應(yīng)用安全的提升需要推動(dòng)移動(dòng)操作系統(tǒng)往更安全的方向演進(jìn)。在未來的進(jìn)一步研究中，可以操作系統(tǒng)的底層安全機(jī)制為深化研究的方向，推動(dòng)從操作系統(tǒng)到上層應(yīng)用的移動(dòng)終端一體化安全。

1 DAC的維基百科.http://en.wikipedia.org/wiki/Discretionary_access_control

2 MAC的維基百科.http://en.wikipedia.org/wiki/Mandatory_access_control

3 Android開發(fā)官方文檔.http://developer.android.com/guide/components/index.html

4 Apple iOS開發(fā)官方文檔.https://developer.apple.com/library/iOS/navigation/index.html

5 Robert N M Watson.New approaches to operating system security extensibility.15 JJ Thomson Avenue，Cambridge CB3 0FD，United Kingdom,2012

6 William E,Peter G,Byung-Gon C,et al.TaintDroid:an informationflow tracking system for realtime privacy monitoring on smartphones.9th USENIX Symposiumon Operating Systems Design and Implementation,Vancouver,BC,Canada,2010

7 Dino A,Dai Z.Apple iOS 4 Security Evaluation,2011

8 Sven B,Lucas D,Alexandra D,et al.XManDroid:a New Android Evolution to Mitigate Privilege Escalation Attacks.System Security LabTechnische University at Darmstadt,Germany,2011

9 Rafael F,Christian B,Christoph K,et al.Android OS Security:Risks and Limitations.AISEC Technical Reports,AISEC-TR-2012-001,2012