SELinux 概念

查看此頁面以熟悉 SELinux 概念。

強制存取控制

安全性增強型Linux (SELinux) 是Linux 作業系統的強制存取控制(MAC) 系統。作為 MAC 系統,它與 Linux 熟悉的自主存取控制(DAC)系統不同。在 DAC 系統中,存在所有權概念,特定資源的擁有者可以控制與其關聯的存取權限。這通常是粗粒度的,並且會出現意外的特權升級。然而,MAC 系統會諮詢中央機構來決定所有訪問嘗試。

SELinux 已作為 Linux 安全模組 (LSM) 框架的一部分實現,該框架可識別各種核心物件以及對其執行的敏感操作。在執行這些操作中的每一個時,都會呼叫 LSM 掛鉤函數來根據儲存在不透明安全性物件中的資訊來決定是否應允許該操作。 SELinux 提供了這些鉤子的實作以及對這些安全性物件的管理,它結合自己的策略來確定存取決策。

與其他 Android 安全措施一起,Android 的存取控制策略極大地限制了受感染機器和帳戶的潛在損害。使用 Android 的自主和強制存取控制等工具可以為您提供一種結構,以確保您的軟體僅在最低權限層級運作。這可以減輕攻擊的影響,並降低錯誤進程覆蓋甚至傳輸資料的可能性。

在 Android 4.3 及更高版本中,SELinux 在傳統的自主存取控制 (DAC) 環境之上提供了強制存取控制 (MAC) 保護傘。例如,軟體通常必須以 root 使用者帳戶執行才能寫入原始區塊裝置。在傳統的基於 DAC 的 Linux 環境中,如果 root 使用者受到威脅,則該使用者可以寫入每個原始區塊裝置。但是,SELinux 可用來標記這些設備,以便指派 root 權限的程序只能寫入關聯策略中指定的設備。這樣,進程就無法覆蓋特定原始區塊設備以外的資料和系統設定。

請參閱用例,以了解更多威脅範例以及使用 SELinux 解決這些威脅的方法。

執法級別

SELinux 可以以不同的模式實現:

  • 寬容- SELinux 安全策略不強制執行,僅記錄。
  • 執行- 執行並記錄安全性策略。故障顯示為 EPERM 錯誤。

此選擇是二元的,決定您的策略是採取行動還是僅僅允許您收集潛在的故障。 Permissive 在實施過程中特別有用。

類型、屬性和規則

Android 依賴 SELinux 的類型強制 (TE) 元件來執行其策略。這意味著所有物件(例如檔案、進程或套接字)都有與其關聯的類型。例如,預設情況下,應用程式的類型為untrusted_app 。對於進程來說,它的類型也稱為它的。可以用一個或多個屬性來註解類型。屬性對於同時引用多種類型非常有用。

物件被映射到類別(例如,檔案、目錄、符號連結、套接字),並且每個類別的不同類型的存取權由權限表示。例如,類別file存在open權限。雖然類型和屬性作為 Android SELinux 策略的一部分定期更新,但權限和類別是靜態定義的,很少作為新 Linux 版本的一部分進行更新。

策略規則的形式為: allow source target : class permissions ;在哪裡:

  • - 規則主題的類型(或屬性)。誰在請求存取權限?
  • 目標- 物件的類型(或屬性)。請求的存取權限是什麼?
  • 類別- 正在存取的物件類型(例如檔案、套接字)。
  • 權限- 正在執行的操作(或一組操作)(例如讀取、寫入)。

規則的例子是:

allow untrusted_app app_data_file:file { read write };

這表示允許應用程式讀取和寫入標記為app_data_file的檔案。應用程式還存在其他類型。例如, isolated_app用於其清單中的isolatedProcess=true應用程式服務。 Android 沒有對這兩種類型重複該規則,而是對涵蓋應用程式的所有類型使用名為appdomain的屬性:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

當編寫指定屬性名稱的規則時,名稱會自動擴展到與該屬性關聯的網域或類型的清單。一些值得注意的屬性是:

  • domain - 與所有流程類型相關的屬性,
  • file_type - 與所有檔案類型關聯的屬性。

特別是對於文件訪問,需要考慮多種權限。例如, read權限不足以開啟檔案或對其呼叫stat 。為了簡化規則定義,Android 提供了一組巨集來處理最常見的情況。例如,為了包含缺少的權限(例如open ,上面的規則可以重寫為:

allow appdomain app_data_file:file rw_file_perms;

有關有用巨集的更多範例,請參閱global_macroste_macros檔案。應盡可能使用宏,以協助減少因拒絕相關權限而導致失敗的可能性。

一旦定義了類型,就需要將其與它所代表的檔案或進程關聯起來。有關如何完成此關聯的更多詳細信息,請參閱實作 SELinux 。有關規則的更多信息,請參閱SELinux Notebook

安全上下文和類別

偵錯 SELinux 策略或標記檔案時(透過file_contextsls -Z ),您可能會遇到安全上下文(也稱為label )。例如: u:r:untrusted_app:s0:c15,c256,c513,c768 。安全上下文的格式為: user:role:type:sensitivity[:categories] 。您通常可以忽略上下文userrolesensitivity欄位(請參閱特異性)。 type欄位已在上一節中進行了解釋。 categories是 SELinux 中多層安全性 (MLS)支援的一部分。自 Android S 起,分類用於:

  • 將應用程式資料與其他應用程式隔離,
  • 將應用程式資料從一個實體使用者隔離到另一個實體使用者。

特異性

Android 並未使用 SELinux 提供的所有功能。閱讀外部文件時,請記住以下幾點:

  • AOSP 中的大多數策略都是使用核心策略語言定義的。使用通用中間語言 (CIL) 存在一些例外。
  • SELinux用戶不使用。唯一的使用者定義是u 。必要時,可以使用安全上下文的類別欄位來表示實體使用者。
  • 不使用 SELinux角色和基於角色的存取控制 (RBAC)。定義並使用兩個預設角色: r代表主體, object_r代表客體。
  • 不使用 SELinux敏感性。始終設定預設的s0靈敏度。
  • 不使用 SELinux 布林值。一旦為設備建立了策略,它就不再依賴設備的狀態。這簡化了策略的審核和調試。