Android安全機制介紹

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入手區分問題的根源。