Android安全機制介紹

Android的安全機制包括以下幾個方面：

 

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

 

一、進程沙箱隔離機制

 

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

 

 

二、應用程序簽名機制

 

應用程序包（.apk文件）必須被開發者數字簽名；同一開發者可指定不同的應用程序共享UID，進而運行於同一進程空間，共享資源。

 

 

簽名的過程：

• 生成私有、公共密鑰和公共密鑰證書 • 對應用進行簽名 • 優化應用程序

簽名的作用：

• 識別代碼的作者。 • 檢測應用程序是否發生了改變。 • 在應用程序之間建立信任，以便於應用程序可以安全地共享代碼和數據。

三、權限聲明機制

 

應用程序需要顯式聲明權限、名稱、權限組與保護級別。不同的級別要求應用程序行使此權限時的認證方式不同：Normal級申請即可用；Dangerous級需在安裝時由用戶確認才可用；Signature與Signatureorsystem則必須是系統用戶才可用。 • 通過manifest文件中聲明以下屬性

請求android:name對應的權限。

• 通過以下屬性添加自定義權限

xmlns:android=http://schemas.android.com/apk/res/android

android:name=com.test.android.ACCESS_FRIENDS_LIST

android:description=@string/permission_description

android:label=@string/permission_label

android:protectionLevel=normal />

• 系統組件權限，如activity組件

android:permission=com.test.android.ACCESS_FRIENDS_LIST

 

四、訪問控制機制

 

傳統的 Linux訪問控制機制確保系統文件與用戶數據不受非法訪問。 Linux用戶與權限 • 超級用戶（root），具有最高的系統權限，UID為 0。 • 系統偽用戶，Linux操作系統出於系統管理的需要，但又不願賦予超級用戶的權限，需要將某些關鍵系統應用 文件所有權賦予某些系統偽用戶，其UID范圍為1 ～ 499，系統的偽用戶不能登錄系統。

 

• 普通用戶，只具備有限的訪問權限，UID 為 500 ～ 6000，可以登錄系統獲得 shell

在Linux權限模型下，每個文件屬於一個用戶和一個組，由UID與GID 標識其所有權。針對於文件的具體訪問權限

定義為可讀(r)、可寫(w)與可執行(x)，並由三組讀、寫、執行組成的權限三元組來描述相關權限。

第一組定義文件所有者（用戶）的權限，第二組定義同組用戶（GID 相同但UID 不同的用戶）的權限，第三組定

義其他用戶的權限（GID與UID 都不同的用戶）。

 

五、進程通信機制

 

Binder 進程通信機制提供基於共享內存的高效進程通信；Binder基於Client-Server模式，提供類似COM 與CORBA的輕量級遠程進程調用（RPC）；通過接口描述語言（AIDL）定義接口與交換數據的類型，確保進程 間通信的數據不會溢出越界，污染進程空間。

 

 

六、內存管理機制

 

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

SELinux 擁有三個基本的操作模式

• Disabled：禁用SELinux策略 • Permissive：在Permissive 模式下，SELinux會被啟用但不會實施安全性策略，而只會發出警告及記錄行 動。Permissive模式在排除 SELinux的問題時很有用 • Enforcing：這個缺省模式會在系統上啟用並實施SELinux 的安全性策略，拒絕訪問及記錄行動

SELinux 擁有三種訪問控制方法：

• 強制類型（TE）：TE是針對型策略所采用的主要訪問控制機制 • 基於角色的訪問控制（RBAC）：它以SELinux用戶（未必等同Linux用戶）為基礎，但缺省的針對型策略並未 采用它 • 多層保障（MLS）：未被采用，而且經常隱藏在缺省的針對型策略內。
SELinux策略文件：

• android/external/sepolicy目錄下

• wing-common/sepolicy自定義策略

 

SELinux默認宏：

• global_macros • mls_macros • te_macros
SELinux常見概念
• 主體：在SELinux中主體通常指的是進程。 • 客體：客體通常是一些系統資源（如文件、目錄、套接字、共享內存等）。 • 客體類型：一個客體類別代表某個確定類型（如文件或套接字）的所有資源。 • DAC：Linux基於用戶識別的訪問控制。 • MAC：主體對客體所采用的訪問類型，即強制訪問控制（TE）。 • 類型強制的安全上下文：訪問屬性叫做安全上下文；一個安全上下文包括用戶、角色和類型標識符。
• 域：由於歷史原因，一個進程的類型通常被稱為一個域或域類型。我們認為域、域類型、主體類型和進程類型 都是指相同意思。 • 策略：因為SELinux默認不允許任何訪問，所以在SELinux中，通過allow語句對主體授權對客體的訪問權限。 • 域轉換
SELinux策略

Selinux策略語言目前支持四類AV規則：

allow，dontaudit，auditallow，neverallow規則由四部分組成

• 源類型（SourceType），通常是嘗試訪問進程的域類型。 • 目標類型（TargetType），被進程訪問的客體的類型。 • 客體類別（ObjectClass），允許訪問的客體類型（如file，dir，socket等）。 • 許可（Permission）象征目標允許源類型訪問客體類型的訪問種類。 • 如allowdev_type tmpfs:filesystem associate;
SELinux域轉換
• 域轉換發生條件 • 進程的新域類型對可執行文件類型有entrypoint訪問權限 • 進程的域類型對入口文件類型有execute訪問權限 • 進程當前的域類型對新的域類型有transition訪問權限
SELinux屬性

attribute概念可以被理解為“具有一組共性的type集合”，或者“這組type所具有的共性”。語法如下：

attribute attribute_name;

比如定義一個名為”file_type”的屬性：

attribute file_type;

在定義某個type時建立它與某個attribute的關聯，比如：

type shadow_t,file_type;

使用attribute可以有效地減少類似規則的數目，比如為了讓domain==backup_t能夠讀取文件系統中的所有文

件，則理論上必須為所有可能存在的文件type定義相應的allow規則：

type backup_t;

allow backup_t shadow_t:file read;

allow backup_t var_t:file read;

可以通過attribute來有效解決這個問題，

allow backup_t file_type:file read;

SELinux角色
SELinux通過SC中的role實現了“基於角色的訪問控制”(RBAC－Role Based Access Control)。在SELinux中， 並不直接建立用戶和type之間的聯系，而是通過角色作為橋梁。

user u roles { r }

role r types domain;

SELinux訪問控制
• ls -Z 顯示文件系統客體的安全上下文 • Ps -Z 顯示進程的安全上下文 • 顯示「用戶：角色：類型：安全級別」
SELinux問題分析

當SELinux處於enforcing模式下時某些程序的執行會失敗，在這裡總結此類問題的總體分析方法。

• 首先排除DAC權限的問題，使用“ls –l”檢查相關文件的屬主和權限。如果DAC的權限許可，則就是SELinux的策略顯式地拒絕了當前操作的執行。 • 然後檢查用戶當前所扮演的角色，某些操作只有特定的角色才有足夠的權限執行。 • 進入permissive模式，從分析失敗操作相應的AVC Denied Msg入手區分問題的根源。