Android安全機制介紹
Android的安全機制包含下面幾個方面：
? 進程沙箱隔離機制。 ? 應用程序簽名機制。 ? 權限聲明機制。 ? 訪問控制機制。 ? 進程通信機制。 ? 內存管理機制。 ? SELinux
一、進程沙箱隔離機制
Android應用程序在安裝時被賦予獨特的用戶標識（UID），並永久保持；應用程序及其執行的Dalvik虛擬機執行於獨立的Linux進程空間。與UID不同的應用程序全然隔離。
二、應用程序簽名機制
應用程序包（簽名的過程：
? 生成私有、公共密鑰和公共密鑰證書 ? 相應用進行簽名 ? 優化應用程序簽名的作用：
? 識別代碼的作者。 ? 檢測應用程序是否發生了改變。 ? 在應用程序之間建立信任，以便於應用程序能夠安全地共享代碼和數據。三、權限聲明機制
應用程序須要顯式聲明權限、名稱、權限組與保護級別。不同的級別要求應用程序行使此權限時的認證方式不同：
<uses-permissionandroid:name="string" />
請求android:name相應的權限。
? 通過下面屬性加入自己定義權限<permission
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組件<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_macrosSELinux常見概念
? 主體：在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入手區分問題的根源。Android安全機制介紹