談談我對Android安全機制的理解

本文從Android系統架構著手，分析Android的安全機制以SE Android，最後給出一些Android安全現狀和常見的安全解決方案。

1、Android系統架構

Android采用分層的系統架構，由下往上分別是linux內核層、硬件抽象層、系統運行時庫層、應用程序框架層和應用程序層。

Android以Linux操作系統內核為基礎，實現硬件設備驅動、進程和內存管理、網絡協議棧、電源管理等核心系統功能。除此以外，Android還增加了一些面向移動設備的特有功能，如低內存管理LMK(Low Memory Killer)、匿名共享內存(Ashmem: Anonymous Shared Memory)，以及進程間通信Binder機制。這些功能的增強進一步提升了Android在內存管理、進程間通信等方面的安全性。

Android之前的版本並不存在硬件抽象層。鑒於硬件廠商並不希望公開其設備驅動的源代碼，Google對此將Linux內核驅動程序進行封裝，屏蔽掉底層的實現細節，向上提供統一的接口，這就是硬件抽象層。

HAL(Hardware Abstraction Layer)規定了一套應用層對硬件層的讀寫和配置的統一接口，本質上是將硬件的驅動分為用戶空間和內核空間，其中內核驅動程序運行在內核空間，HAL運行在用戶空間。上圖中的Stub，以so庫的形式存在，可以理解為proxy。上層通過調用標識獲得HAL的相關Stub，進而取得相應操作。

系統運行時庫由系統類庫和Android運行時構成。系統類庫基本上用C/C++編寫，基本功能說明如下：

系統類庫 功能說明 Surface Manager 執行多個應用程序時，管理子系統顯示，對2D和3D圖形提供支持 Media Framework 基於PacketVideoOpenCore多媒體庫，支持多種常用的音頻視頻格式錄制和回放。支持的編碼格式包括MPEG4、MP3、H.264、AAC、ARM SQLite 本地小型關系型數據庫，以代替傳統的耗費資源JDBC API OpenGL | ES 基於OpenGL ES 1.0 API標准實現的3D跨平台圖形庫 FreeType 用於顯示位圖和矢量字體 Webkit Web浏覽器軟件引擎 SSL 安全套接層 SGL 底層2D圖形引擎 Libc(bionic libc) 繼承自BSD的C函數庫bionic libc，更適合基於嵌入式Linux的移動設備

當然，還有Android NDK(Native Development Kit)，使得應用程序可以不依賴Dalvik虛擬機進行開發。Android運行時核心庫提供android.os, android.net, android.media等核心API，而Dalvik虛擬機依賴Linux內核，實現進程隔離與線程調度管理、安全與異常管理、垃圾回收等功能，並被改進以適應低內存、低處理器速度的移動設備環境。

再往上就是應用程序框架層了。一系列的Android應用程序所需的類庫，使得開發人員可以快速地進行程序開發，也可以通過繼承實現個性化的擴展。如Activity Manager負責主線程ActivityThread的創建、Activity生命周期的維護，並為窗口提供交互的接口。

應用層就是與用戶直接交互的應用程序，如SMS短信、圖片浏覽器、地圖以及開發人員所開發的應用程序。

2、Android安全機制

Android將安全設計貫穿系統架構的各個層面，覆蓋系統內核、虛擬機、應用程序框架層以及應用層各個環節，力求在開放的同時，也恰當保護用戶的數據、應用程序和設備的安全。Android安全模型主要提供以下幾種安全機制：

• 進程沙箱隔離機制
• 應用程序簽名機制
• 權限聲明機制
• 訪問控制機制
• 進程通信機制
• 內存管理機制

進程沙箱隔離機制，使得Android應用程序在安裝時被賦予獨特的用戶標識（UID），並永久保持。應用程序及其運行的Dalvik虛擬機運行在獨立的Linux進程空間，與其它應用程序完全隔離。

在特殊情況下，進程間還可以存在相互信任關系。如源自同一開發者或同一開發機構的應用程序，通過Android提供的共享UID（Shared UserId）機制，使得具備信任關系的應用程序可以運行在同一進程空間。

應用程序簽名機制，規定APK文件必須被開發者進行數字簽名，以便標識應用程序作者和在應用程序之間的信任關系。在安裝應用程序APK時，系統安裝程序首先檢查APK是否被簽名，有簽名才能安裝。當應用程序升級時，需要檢查新版應用的數字簽名與已安裝的應用程序的簽名是否相同，否則，會被當做一個新的應用程序。Android開發者有可能把安裝包命名為相同的名字，通過不同的簽名可以把他們區分開來，也保證簽名不同的包不被替換，同時防止惡意軟件替換安裝的應用。

權限聲明機制，要想獲得在對象上進行操作，就需要把權限和此對象的操作進行綁定。不同級別要求應用程序行使權限的認證方式也不一樣，Normal級申請就可以使用，Dangerous級需要安裝時由用戶確認，Signature和Signatureorsystem級則必須是系統用戶才可用。

訪問控制機制，確保系統文件和用戶數據不受非法訪問。

進程通信機制，基於共享內存的Binder實現，提供輕量級的遠程進程調用（RPC）。通過接口描述語言（AIDL）定義接口與交換數據的類型，確保進程間通信的數據不會溢出越界。

Linux進程視角

應用程序視角

內存管理機制，基於Linux的低內存管理機制，設計實現了獨特的LMK，將進程重要性分級、分組，當內存不足時，自動清理級別進程所占用的內存空間。同時，引入的Ashmem內存機制，使得Android具備清理不再使用共享內存區域的能力。

正是因為Android采用多層架構，在保護信息安全的同時，也保證開放平台的靈活性。

3、SE Android

Android是一個基於Linux內核的系統，像傳統的Linux系統一樣，Android也有用戶的概念。只不過這些用戶不需要登錄，也可以使用Android系統。Android系統將每一個安裝在系統的APK都映射為一個不同的Linux用戶。也就是每一個APK都有一個對應的UID和GID，這些UID和GID在APK安裝的時候由系統安裝服務PackageManagerService分配。Android沙箱隔離機制就是建立在Linux的UID和GID基礎上。

這種基於Linux UID/GID的安全機制存在什麼樣的問題呢？

Linux將文件的權限劃分為讀、寫和執行三種，分別用字母r、w和x表示。每一個文件有三組讀、寫和執行權限，分別針對文件的所有者、文件所有者所屬的組以及除了所有者以及在所有者所屬組的用戶之外所有其它用戶。這樣，如果一個用戶想要將一個自己創建的文件交給另外一個用戶訪問，那麼只需要相應地設置一下這個文件的其它用戶權限位就可以了。所以，在Linux系統中，文件的權限控制在所有者的手中。因此，這種權限控制方式就稱為自主式的，正式的英文名稱為Discretionary Access Control，簡稱為DAC。

在理想情況下，DAC機制是沒有問題的。然而，一個用戶可能會不小心將自己創建的文件的權限位錯誤地修改為允許其它用戶訪問。如果這個用戶是一個特權用戶，並且它錯誤操作的文件是一個敏感的文件，那麼就會產生嚴重的安全問題。這種誤操作的產生方式有三種：

• 用戶執行了錯誤的命令
• 負責執行用戶命令的程序有Bug
• 負責執行用戶命令的程序受到攻擊

後來，Linux內核采用了必要的訪問控制機制：SE Linux（Security-Enhanced Linux），它采用了一種強制存取控制MAC（Mandatory Access Control）策略的實現方式，目的在於通過限制系統中的任何進程以及用戶對資源的訪問，保護內核安全。而SE Android（Security-Enhanced Android）是Android與SE Linux的結合，由美國NSA在2012年推出的Android操作系統安全強化套件，以支持在Android平台上使用SE Linux。

目前SE Android系統中的策略機制主要有三種：

• 安裝時MAC（install-time MAC）
• 權限取消（permission revocation）
• 權限標簽傳播（tag propagation）

安裝時MAC通過查找MAC策略配置來檢查應用程序的權限。權限取消可以為已安裝的應用取消權限，該機制在應用程序運行的權限檢查時通過查找權限取消列表來取消應用的某些權限。權限標簽傳播是一種污點跟蹤方式的應用，Android系統的權限作為抽象的標簽映射到MAC策略配置文件中。

SE Android安全機制所要保護的對象是系統中的資源，這些資源分布在各個子系統中。實際上，系統中需要保護的資源非常多，除了文件之外，還有進程、socket和IPC等。SE Android是一個復雜的安全模型，本文就不進一步分析了。想了解更多，請參考：SEAndroid安全機制框架分析

4、Android應用安全解決方案

Android應用會遇到各種各樣的安全性問題，如何從宏觀上了解各種安全隱患，積極采取適當的防御措施便變得尤為重要。那麼，Android應用面臨哪些安全問題呢？

• 病毒
• 關鍵信息洩露
• APP重打包
• 進程被劫持
• 數據在傳輸過程遭劫持
• Webview漏洞

病毒不用多說了，都是一些惡意軟件。關鍵信息洩露，可能有些開發者並不十分留意。雖然Java代碼可以做混淆，但是Android的幾大組件的創建方式是依賴注入的方式，因此不能被混淆。而且目前常用的一些反編譯工具比如apktool等能夠毫不費勁地還原Java裡的明文信息，native裡的庫信息也可以通過objdump或IDA獲取。因此一旦Java或native代碼裡存在明文敏感信息，基本上就是毫無安全而言的。重打包即通過反編譯後重新加入惡意的代碼邏輯，重新打包一個APK文件。進程被劫持一般通過進程注入或者調試進程的方式來hook進程，改變程序運行的邏輯和順序，從而獲取程序運行的內存信息。hook需要獲取root權限或者跟被hook進程相同的權限。如果手機沒被root，被劫持的可能性還是較小。數據在傳輸過程遭劫持，一般來說是由於數據明文傳輸或沒使用HTTPS。Webview漏洞一般由於JS注入。

現實中，出現的問題可能比上面提及的還要多。總的來說，應該從以下幾個方面來應對Android開發的常見安全問題：

• 應用權限控制。通過控制應用程序的權限防止惡意應用對系統造成破壞，采取的措施包括合理使用系統內置權限和應用程序自定義權限。
• 應用程序簽名。采用數字簽名為應用程序簽名。
• 應用加固。應用加固包括病毒掃描、防注入、防調試、防篡改四個模塊，目前行業內已經出現了很多的應用加固解決方案，如360應用加固、騰訊雲應用加固、百度應用加固等等。
• 靜態代碼分析。通過靜態代碼分析工具lint監測安全隱患，對代碼進行優化。
• 防火牆。必要時為Android設備安裝防火牆，以防止遠程網絡攻擊。
• 數據存儲加密。采用加密的方式保護應用程序敏感數據，如利用SQLCipher加密SQLite數據庫。
• 應用程序組件開發的安全要點。Activity, Service, Content Provider, Broadcast Receiver等組件在代碼層面應采取的安全措施。它們每一個都可以通過隱式的Intent方式打開，所以這些組件只要不是對外公開的必須在AndroidManifest裡面注明exported為false，禁止其它程序訪問我們的組件。對於要和外部交互的組件，應當添加訪問權限的控制，還需要要對傳遞的數據進行安全的校驗。