政策兼容性

本文介紹了 Android 如何處理平台 OTA 的策略兼容性問題,其中新平台 SELinux 設置可能與舊供應商 SELinux 設置不同。

基於高音SELinux策略的設計充分考慮平台供應商的政策之間的二元區分;該計劃變得更加複雜,如果供應商分區產生依賴性,如platform < vendor < oem

在 Android 8.0 及更高版本中,SELinux 全局策略分為私有和公共組件。公共組件由策略和相關基礎設施組成,保證可用於平台版本。此策略將公開給供應商策略編寫者,使供應商能夠構建供應商策略文件,當與平台提供的策略結合時,會為設備生成功能齊全的策略。

  • 對於版本,導出平台的公共政策將被寫入作為屬性
  • 為便於政策的寫作,出口種類將被改造成版本屬性作為策略構建過程的一部分。公共類型也可以直接用於供應商上下文文件提供的標籤決策中。

安卓維持平台策略出口的具體類型,並為每個平台版本對應的版本屬性之間的映射。這確保了當對像被標記為類型時,它不會破壞先前版本中平台公共策略所保證的行為。這種映射通過保持一個映射文件了最新的維護各平台版本,這使屬性成員信息為每種類型的公共政策出口。

對象所有權和標籤

在 Android 8.0 及更高版本中自定義政策時,必須為每個對像明確定義所有權,以保持平台和供應商政策分開。例如,如果供應商標籤/dev/foo和平台,然後標籤/dev/foo在隨後的OTA,會有不確定的行為。對於 SELinux,這表現為標籤衝突。設備節點只能有一個標籤,該標籤解析為最後應用的標籤。其結果:

  • 流程,對失敗標籤的應用需要訪問將失去對資源的訪問。
  • 流程,該文件獲得進入可能中斷,因為錯誤的設備節點創建。

系統屬性也有可能導致命名衝突,這可能導致系統上的未定義行為(以及 SELinux 標籤)。任何具有 SELinux 標籤的對象(包括屬性、服務、進程、文件和套接字)都可能發生平台和供應商標籤之間的衝突。為避免這些問題,請明確定義這些對象的所有權。

除了標籤衝突之外,SELinux 類型/屬性名稱也可能發生衝突。類型/屬性名稱衝突將始終導致策略編譯器錯誤。

類型/屬性命名空間

SELinux 不允許同一類型/屬性的多個聲明。具有重複聲明的策略將無法編譯。為了避免類型和屬性名稱衝突,所有供應商的聲明應開始進行命名空間np_

type foo, domain; → type np_foo, domain;

系統屬性和進程標籤所有權

避免標籤衝突最好使用屬性命名空間來解決。為了在重命名或添加導出的平台屬性時輕鬆識別平台屬性並避免名稱衝突,請確保所有供應商屬性都有自己的前綴:

財產種類可接受的前綴
可讀寫vendor.
只讀ro.vendor.
ro.boot.
ro.hardware.
執著的persist.vendor.

供應商可以繼續使用ro.boot.* (這是從內核CMDLINE)和ro.hardware.* (一個明顯的硬件相關的屬性)。

在初始化RC文件中的所有供應商的服務應該有vendor.用於非系統分區的 init rc 文件中的服務。類似的規則被應用到用於供應商屬性SELinux的標籤( vendor_為供應商屬性)。

文件所有權

防止文件衝突具有挑戰性,因為平台和供應商策略通常都為所有文件系統提供標籤。與類型命名不同,文件的命名空間並不實用,因為其中許多是由內核創建的。為防止這些衝突,請遵循本節中文件系統的命名指南。對於 Android 8.0,這些是沒有技術強制執行的建議。在未來,這些建議將被強制執行賣方測試套件(VTS)。

系統(/系統)

只有系統映像必須提供標籤/system通過組件file_contextsservice_contexts等。如果標籤/system組件中添加/vendor政策,框架,僅OTA更新是不可能的。

供應商(/供應商)

該AOSP SELinux策略已經標註的零件vendor分區與平台進行交互,從而允許寫的SELinux規則平台的過程才能夠說話和/或接入部分vendor分區。例子:

/vendor路徑平台提供的標籤平台進程取決於標籤
/vendor(/. * )? vendor_file在框架中,所有HAL客戶ueventd等。
/vendor/framework(/. * )? vendor_framework_file dex2oatappdomain ,等等。
/vendor/app(/. * )? vendor_app_file dex2oatinstalldidmap等。
/vendor/overlay(/. * ) vendor_overlay_file system_serverzygoteidmap等。

其結果是,特定的規則必須遵循(通過強迫neverallows標記在其他文件時) vendor的分區:

  • vendor_file必須在所有文件的默認標籤vendor分區。平台策略要求使用它來訪問直通 HAL 實現。
  • 所有新exec_types在增加vendor通過供應商SEPolicy分區必須有vendor_file_type屬性。這是通過 neverallows 強制執行的。
  • 為了避免未來平台/架構的更新,比其他忌標籤文件有衝突exec_typesvendor分區。
  • 所有依賴庫的AOSP確定的同一過程的HAL必須標示為same_process_hal_file.

進程 (/proc)

在文件/proc可以僅使用標記genfscon標籤。在安卓7.0,無論是平台供應商的策略中使用的genfscon標註文件procfs

建議:只有平台策略標籤/proc 。如果vendor過程中需要訪問的文件中/proc當前標記默認標籤( proc ),供應商的政策應該沒有明確標記他們,而應使用通用proc類型添加規則廠商域。這使得平台的更新,以適應通過暴露未來內核接口procfs ,並根據需要明確地標記它們。

調試文件 (/sys/kernel/debug)

Debugfs可以在兩個標記file_contextsgenfscon 。在安卓7.0到Android 10,這兩個平台和供應商的標籤debugfs

在Android中11, debugfs不能被訪問或安裝在生產設備。設備製造商應該刪除debugfs

Tracefs (/sys/kernel/debug/tracing)

Tracefs可以在兩個標記file_contextsgenfscon 。在安卓7.0,只有平台標籤tracefs

建議:唯一平台可以標註tracefs

系統文件 (/sys)

在文件/sys可以使用兩個標記file_contextsgenfscon 。在安卓7.0,這兩個平台和供應商使用file_contextsgenfscon標註文件在sysfs

建議:該平台可以標註sysfs不屬於設備特定的節點。否則,只有供應商可以標記文件。

tmpfs (/dev)

在文件中/dev可能被標記file_contexts 。在 Android 7.0 中,此處包含平台和供應商標籤文件。

建議:賣方可能只標記文件中/dev/vendor (例如, /dev/vendor/foo/dev/vendor/socket/bar )。

根文件 (/)

在文件/可能被標記file_contexts 。在 Android 7.0 中,此處包含平台和供應商標籤文件。

建議:只有系統可以在標籤文件/

數據(/數據)

數據通過的組合標記file_contextsseapp_contexts

建議:不允許供應商標籤外/data/vendor 。只有平台可標註的其他部分/data

兼容性屬性

SELinux 策略是特定對像類和權限的源和目標類型之間的交互。每個受 SELinux 策略影響的對象(進程、文件等)可能只有一種類型,但該類型可能有多種屬性。

策略主要是根據現有類型編寫的:

allow source_type target_type:target_class permission(s);

這是有效的,因為該策略是在了解所有類型的情況下編寫的。但是,如果供應商策略和平台策略使用特定類型,並且特定對象的標籤僅在這些策略中的一個中更改,則另一個可能包含獲得或丟失先前依賴的訪問權限的策略。例如:

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

可以改為:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

雖然供應商的政策將保持不變,則v_domain將失去因缺乏政策的新接sysfs_A類型。

通過根據屬性定義策略,我們可以為底層對象提供一個類型,該類型具有與平台和供應商代碼的策略對應的屬性。這可以為所有類型進行有效地創建一個屬性的策略,其中具體類型從未使用過。在實踐中,這僅需要對策略的該平台和供應商之間重疊的部分,其被定義並且為被構建為供應商策略的一部分平台公共政策提供。

將公共政策定義為版本化屬性滿足兩個政策兼容性目標:

  • 確保供應商代碼繼續工作平台更新後。通過為與供應商代碼所依賴的對象相對應的對象的具體類型添加屬性來實現,保留訪問權限。
  • 能夠棄用政策。通過將策略集清楚地描述為屬性,一旦不再支持它們對應的版本,就可以刪除這些屬性。可以在平台中繼續開發,知道舊策略仍然存在於供應商策略中,並且會在升級時/如果升級時自動刪除。

策略可寫性

為了實現不需要了解特定版本更改以進行策略開發的目標,Android 8.0 包括平台公共策略類型及其屬性之間的映射。類型foo映射到屬性foo_v N ,其中N是有針對性的版本。 vN對應於PLATFORM_SEPOLICY_VERSION構建變量和的形式為MM.NN ,其中MM對應於平台SDK數目和NN是一個平台sepolicy特定版本。

公共策略中的屬性沒有版本化,而是作為 API 存在,平台和供應商策略可以在該 API 上構建以保持兩個分區之間的接口穩定。平台和供應商策略編寫者都可以繼續編寫今天編寫的策略。

平台的公共政策導出為allow source_foo target_bar: class perm ;包含在供應商政策中。在編譯(其包括對應版本)它被轉換成將轉到設備(在轉化的公共中間語言(CIL)示出)的供應商部分的策略:

 (allow source_foo_vN target_bar_vN (class (perm)))

由於供應商政策永遠不會領先於平台,因此不應關注以前的版本。但是,平台策略需要知道供應商策略有多遠,包括其類型的屬性,並設置與版本化屬性相對應的策略。

政策差異

通過加入自動創建屬性_v N每種類型的端部不執行任何操作而無需跨越版本的diff屬性類型的映射。 Android 維護屬性版本之間的映射以及類型到這些屬性的映射。這是在前面提到的帶有語句的映射文件中完成的,例如 (CIL):

(typeattributeset foo_vN (foo))

平台升級

以下部分詳細介紹了平台升級的場景。

相同類型

當對象未更改策略版本中的標籤時,就會發生這種情況。這是源和目標類型相同,並且可以與可以看到/dev/binder ,將其標記binder_device跨所有版本。它在轉換後的策略中表示為:

binder_device_v1 … binder_device_vN

當升級從v1v2 ,平台策略必須包含:

type binder_device; -> (type binder_device) (in CIL)

在 v1 映射文件 (CIL) 中:

(typeattributeset binder_device_v1 (binder_device))

在 v2 映射文件 (CIL) 中:

(typeattributeset binder_device_v2 (binder_device))

在 v1 供應商政策 (CIL) 中:

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

在 v2 供應商政策 (CIL) 中:

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
新類型

這種情況發生在平台添加了新類型時,這可能發生在添加新功能或策略強化期間。

  • 新功能。當類型標記以前不存在的對象(例如新的服務進程)時,供應商代碼以前沒有直接與其交互,因此不存在相應的策略。對應於該類型的新屬性在以前的版本中沒有屬性,因此在針對該版本的映射文件中不需要條目。
  • 政策硬化。當類型表示政策硬化,新類型屬性必須鏈接回對應於前一個屬性的鏈(改變類似於前面的實施例/sys/Asysfssysfs_A )。供應商代碼依賴於規則使得能夠訪問sysfs ,並需要包括規則作為新的類型的屬性。

當升級從v1v2 ,平台策略必須包含:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

在 v1 映射文件 (CIL) 中:

(typeattributeset sysfs_v1 (sysfs sysfs_A))

在 v2 映射文件 (CIL) 中:

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

在 v1 供應商政策 (CIL) 中:

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

在 v2 供應商政策 (CIL) 中:

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
刪除的類型

這種(罕見的)場景發生在一個類型被移除時,這可能發生在底層對象:

  • 保留,但獲得不同的標籤。
  • 被平台移除。

在政策鬆動期間,一個類型被移除,並且標有該類型的對像被賦予一個不同的、已經存在的標籤。這代表了屬性映射的合併:供應商代碼仍然必須能夠通過它曾經擁有的屬性訪問底層對象,但係統的其餘部分現在必須能夠使用其新屬性訪問它。

如果它被切換到的屬性是新的,那麼重新標記與新類型的情況相同,除了當使用現有標籤時,舊屬性新類型的添加會導致其他對像也被標記為該類型新近訪問。這本質上是平台所做的,並且被認為是保持兼容性的可接受的折衷。

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

示例版本 1:折疊類型(刪除 sysfs_A)

當升級從v1v2 ,平台策略必須包含:

type sysfs; (type sysfs) (in CIL)

在 v1 映射文件 (CIL) 中:

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

在 v2 映射文件 (CIL) 中:

(typeattributeset sysfs_v2 (sysfs))

在 v1 供應商政策 (CIL) 中:

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

在 v2 供應商政策 (CIL) 中:

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

示例版本 2:完全刪除(foo 類型)

當升級從v1v2 ,平台策略必須包含:

# nothing - we got rid of the type

在 v1 映射文件 (CIL) 中:

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

在 v2 映射文件 (CIL) 中:

# nothing - get rid of it

在 v1 供應商政策 (CIL) 中:

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

在 v2 供應商政策 (CIL) 中:

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
新類/權限

當平台升級引入了以前版本中不存在的新策略組件時,就會發生這種情況。例如,當Android的加入servicemanager創建附加,查找和列表的權限,供應商守護希望與登記對象管理servicemanager是無法獲得所需的權限。在 Android 8.0 中,只有平台策略可以添加新的類和權限。

為了允許供應商策略創建或擴展的所有域不受阻礙地使用新類,平台策略需要包含類似於以下內容的規則:

allow {domain -coredomain} *:new_class perm;

這甚至可能需要允許訪問所有接口(公共策略)類型的策略,以確保供應商圖像獲得訪問權限。如果這導致不可接受的安全策略(因為它可能隨著 servicemanager 更改而產生),則可能會強制供應商升級。

刪除的類/權限

當對象管理器移除(如出現這種情況下ZygoteConnection對象管理器)和不應引起的問題。對像管理器類和權限可以在策略中保持定義,直到供應商版本不再使用它。這是通過將定義添加到相應的映射文件來完成的。

新/重新標記類型的供應商定制

新的供應商類型是供應商政策制定的核心,因為需要它們來描述新的流程、二進製文件、設備、子系統和存儲的數據。因此,必須允許創建供應商定義的類型。

由於供應商策略始終是設備上最早的,因此無需將所有供應商類型自動轉換為策略中的屬性。平台不依賴供應商政策中標記的任何內容,因為平台對此一無所知;然而,該平台將提供它使用與標記的與這些類型的(如對象交互屬性和公共類型domainsysfs_type等)。對於平台繼續與這些對象正確地相互作用,所述屬性和類型必須被適當地應用和具體的規則可能需要被添加到該可定制的結構域(如init )。

Android 9 的屬性更改

升級到 Android 9 的設備可以使用以下屬性,但搭載 Android 9 的設備不得使用。

違規者屬性

Android 9 包含以下與域相關的屬性:

  • data_between_core_and_vendor_violators 。屬性對於違反不受之間的路徑共享文件要求所有域vendorcoredomains 。平台和供應商進程不應使用磁盤文件進行通信(不穩定的 ABI)。推薦:
    • 供應商代碼應該使用/data/vendor
    • 系統不應該使用/data/vendor
  • system_executes_vendor_violators 。屬性對所有系統域(除了initshell domains違反不執行供應商的二進制文件的要求)。供應商二進製文件的執行具有不穩定的 API。平台不應直接執行供應商二進製文件。推薦:
    • 這種對供應商二進製文件的平台依賴性必須位於 HIDL HAL 之後。

      或者

    • coredomains ,為供應商的程序需要訪問應該被移動到供應商分區,因此,不要再coredomain

不受信任的屬性

託管任意代碼的不受信任的應用程序不應訪問 HwBinder 服務,除非那些被認為足以安全地從此類應用程序訪問的應用程序(請參閱下面的安全服務)。造成這種情況的兩個主要原因是:

  1. HwBinder 服務器不執行客戶端身份驗證,因為 HIDL 當前不公開調用方 UID 信息。即使 HIDL 確實公開了此類數據,許多 HwBinder 服務要么在低於應用(例如 HAL)的級別上運行,要么不得依賴應用身份進行授權。因此,為了安全起見,默認假設是每個 HwBinder 服務都將其所有客戶端視為同等授權來執行服務提供的操作。
  2. HAL服務器(的HwBinder服務的子集)包含代碼的比安全問題的高發病率system/core組件,並有機會獲得棧的較低層(一切歸因於硬件的方式),從而增加了繞過Android安全模型的機會.

安全服務

安全服務包括:

  • same_process_hwservice 。這些服務(根據定義)在客戶端進程中運行,因此具有與進程運行所在的客戶端域相同的訪問權限。
  • coredomain_hwservice 。這些服務不會帶來與原因#2 相關的風險。
  • hal_configstore_ISurfaceFlingerConfigs 。此服務專為任何域使用而設計。
  • hal_graphics_allocator_hwservice 。這些操作也可以通過提供surfaceflinger活頁夾服務,應用程序被允許訪問。
  • hal_omx_hwservice 。這是一個HwBinder版本mediacodec粘合劑服務,應用程序被允許訪問。
  • hal_codec2_hwservice 。這是一個較新的版本hal_omx_hwservice

可用屬性

所有hwservices沒有考慮安全具有屬性untrusted_app_visible_hwservice 。相應的HAL服務器具有屬性untrusted_app_visible_halserver 。設備與Android 9必須在啟動無法使用任何一個untrusted屬性。

推薦:

  • 不受信任的應用程序應改為與與供應商 HIDL HAL 對話的系統服務對話。例如,應用程序可以跟binderservicedomain ,然後mediaserver (這是一個binderservicedomain )輪流舉行會談的hal_graphics_allocator

    或者

  • 需要直接訪問應用程序vendor的HAL應該有自己的供應商定義的sepolicy域。

文件屬性測試

機器人9包括編譯時間的測試,以確保在特定位置的所有文件都具有適當屬性(例如,在所有文件sysfs具有所需sysfs_type屬性)。

平台-公共政策

平台公共策略是符合 Android 8.0 架構模型的核心,而不是簡單地維護 v1 和 v2 的平台策略的聯合。供應商暴露在平台策略的一個子集,其中包含可用的類型和這些類型和屬性然後成為供應商策略的一部分(即屬性和規則vendor_sepolicy.cil )。

類型和規則被供應商生成的策略到自動翻譯attribute_v N使得所有平台提供的類型版本屬性(然而屬性不是版本)。平台負責將其提供的具體類型映射到適當的屬性,以確保供應商政策繼續發揮作用,並包括為特定版本提供的規則。平台公共政策和供應商政策的結合滿足了 Android 8.0 架構模型目標,即允許獨立的平台和供應商構建。

映射到屬性鏈

當使用屬性映射到策略版本時,一個類型映射到一個屬性或多個屬性,確保標記有該類型的對象可以通過與其先前類型相對應的屬性進行訪問。

保持對策略編寫者隱藏版本信息的目標意味著自動生成版本化屬性並將它們分配給適當的類型。在靜態類型的常見的情況,這很簡單: type_foo映射到type_foo_v1

為對象的標籤改變,諸如sysfssysfs_Amediaserveraudioserver ,創建此映射是不平凡的(和在上面的例子中描述了)。平台策略維護者必須確定如何在對象的轉換點創建映射,這需要了解對象與其分配的標籤之間的關係並確定何時發生。為了向後兼容,這種複雜性需要在平台端進行管理,這是唯一可以升級的分區。

版本升級

為簡單起見,Android 平台會在新的發布分支被剪切時發布一個 sepolicy 版本。如上所述,版本號被包含在PLATFORM_SEPOLICY_VERSION和的形式為MM.nn ,其中MM對應於SDK值和nn是保持在私有值/platform/system/sepolicy.例如, 19.0為奇巧, 21.0為棒棒糖, 22.0為棒棒糖-MR1 23.0用於棉花糖, 24.0對牛軋糖, 25.0對牛軋糖-MR1, 26.0為奧利奧, 27.0為奧利奧-MR1,和28.0的Android 9. Uprevs不總是整數。例如,如果一個MR凸起的版本,在必要的不兼容的更改system/sepolicy/public但不是一個API磕碰,那麼sepolicy版本可能是: vN.1 。目前在開發分支的版本是一個永不將要使用的功能於航運設備10000.0

Android 可能會在升級時棄用最舊的版本。對於何時棄用某個版本的輸入,Android 可能會收集具有運行該 Android 版本並仍接收主要平台更新的供應商政策的設備數量。如果數量小於某個閾值,則不推薦使用該版本。

多個屬性的性能影響

正如在描述https://github.com/SELinuxProject/cil/issues/9 ,分配了大量的屬性的類型導致的性能問題的策略高速緩存未命中的情況。

這被證實是Android的一個問題,所以進行了更改到Android 8.0,以消除政策編譯器添加到策略屬性,以及刪除未使用的屬性。這些更改解決了性能回歸問題。

SELinux 上下文標記

為了支持平台和供應商 sepolicy 之間的區別,系統以不同的方式構建 SELinux 上下文文件以將它們分開。

文件上下文

的Android 8.0引入了以下變化file_contexts

  • 為了避免在引導過程中對設備的附加編譯開銷, file_contexts停止在二進制形式存在。相反,它們是可讀的,正則表達式的文本文件比如{property, service}_contexts (因為它們是預7.0)。
  • file_contexts兩個文件之間的分裂:
    • plat_file_contexts
      • Android平台file_context有沒有設備專用標籤,除了貼標籤的部件/vendor必須精確標記,以確保sepolicy文件的正常功能分區。
      • 必須駐留在system在分區/system/etc/selinux/plat_file_contexts器件和由加載init與供應商一起在開始file_context
    • vendor_file_contexts
      • 設備特定file_context結合內置file_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
      • 必須在安裝/vendor/etc/selinux/vendor_file_contextsvendor分區,並通過加載init與平台一起在開始file_context

屬性上下文

在安卓8.0中, property_contexts是兩個文件之間的分裂:

  • plat_property_contexts
    • Android平台property_context有沒有設備專用標籤。
    • 必須駐留在system在分區/system/etc/selinux/plat_property_contexts和由加載init與供應商一起在開始property_contexts
  • vendor_property_contexts
    • 設備特定property_context結合內置property_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須駐留在vendor在分區/vendor/etc/selinux/vendor_property_contexts並加載init與平台一起在開始property_context

服務上下文

在安卓8.0中, service_contexts是下列文件之間的分裂:

  • plat_service_contexts
    • Android平台專用service_contextservicemanager 。該service_context沒有設備專用標籤。
    • 必須駐留在system在分區/system/etc/selinux/plat_service_contexts和由加載servicemanager與供應商一起在開始service_contexts
  • vendor_service_contexts
    • 設備特定service_context結合內置service_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須駐留在vendor在分區/vendor/etc/selinux/vendor_service_contexts和加載servicemanager與平台一起在開始service_contexts
    • 雖然servicemanager看起來在啟動時這個文件,完全兼容TREBLE裝置,該vendor_service_contexts必須不存在。這是因為之間的所有互動vendorsystem流程必須經過hwservicemanager / hwbinder
  • plat_hwservice_contexts
    • Android平台hwservice_contexthwservicemanager有沒有設備專用標籤。
    • 必須駐留在system在分區/system/etc/selinux/plat_hwservice_contexts和由加載hwservicemanager在與沿開始vendor_hwservice_contexts
  • vendor_hwservice_contexts
    • 設備特定hwservice_context結合內置hwservice_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須駐留在vendor處的分區/vendor/etc/selinux/vendor_hwservice_contexts和由加載hwservicemanager與沿著在開始plat_service_contexts
  • vndservice_contexts
    • 設備特定service_contextvndservicemanager結合內置vndservice_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk
    • 此文件必須駐留在vendor處的分區/vendor/etc/selinux/vndservice_contexts和由加載vndservicemanager在開始。

Seapp 上下文

在安卓8.0中, seapp_contexts是兩個文件之間的分裂:

  • plat_seapp_contexts
    • Android平台seapp_context不具有特定於設備的變化。
    • 必須駐留在system的分區/system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • 特定於設備的擴展平台seapp_context結合內置seapp_contexts通過指向目錄中找到BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須駐留在vendor在分區/vendor/etc/selinux/vendor_seapp_contexts

MAC權限

在安卓8.0中, mac_permissions.xml是兩個文件之間的分裂:

  • 平台mac_permissions.xml
    • Android平台mac_permissions.xml不具有特定於設備的變化。
    • 必須駐留在system的分區/system/etc/selinux/.
  • 非平台mac_permissions.xml
    • 特定於設備的擴展平台mac_permissions.xml從內置mac_permissions.xml通過指向目錄中找到BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須駐留在vendor在分區/vendor/etc/selinux/.