政策適用範圍

本文說明 Android 如何處理政策相容性問題 ，但新平台的 SELinux 設定可能與舊版供應商不同 SELinux 設定。

以 Treble 為基礎的 SELinux 政策在設計上考量到二元差異 平台和供應商政策之間；配置變為 會比較複雜，如果廠商分區會產生依附元件，例如 platform <vendor <oem。

在 Android 8.0 以上版本中，SELinux 全域政策分為「私人」 公開元件公開元件包含政策和相關元件 提供的基礎架構。 供應商政策寫入者會看見這項政策，供供應商建立 供應商政策檔案，與平台提供的政策搭配使用 政策的目的是為裝置提供完整功能。

• 進行版本管理時，匯出的平台公開政策會以 屬性。
• 為方便撰寫政策，匯出的類型會轉換為 版本化屬性。公有雲 也能直接用於標示供應商提供的標籤 結構定義檔案

Android 會維護平台中匯出的具體類型之間的對應關係 政策和相應版本化屬性 版本。這能確保在物件有類型標籤時 不會違反現行平台公開政策保證的行為 版本。藉由即時更新 對應檔， 每個平台版本，因此保留每個平台版本的屬性資訊 匯出在公開政策中的類型

物件擁有權和標籤

在 Android 8.0 以上版本中自訂政策時，必須明確定義擁有權 ，以便分開管理平台和供應商政策。舉例來說 供應商標籤 /dev/foo，平台則加上標籤 在後續 OTA 中的 /dev/foo 中，會有未定義的行為。適用對象 SELinux，這會成為標籤衝突。裝置節點只能 會解析為最後套用標籤的單一標籤。因此：

• 若處理失敗的標籤需要存取權， 就會失去資源的存取權
• 導致檔案獲得存取權的程序可能會因錯誤錯誤而中斷 已建立裝置節點。

系統屬性還可能造成命名衝突， 系統中未定義的行為 (以及 SELinux 標籤)。碰撞 任何含有 SELinux 的物件，都可能發生「平台」和「供應商標籤」之間的 包括屬性、服務、程序、檔案和通訊端等屬性為了避免 請明確定義這些物件的擁有權

除了標籤衝突外，SELinux 類型/屬性名稱也可能會衝突。 類型/屬性名稱衝突一律會導致政策編譯器發生錯誤。

類型/屬性名稱使用速度

SELinux 不允許多個相同類型/屬性的宣告。政策 重複的宣告將無法編譯。若要避免輸入 屬性名稱衝突，所有供應商宣告都應該有命名空間 開頭為「vendor_」。

type foo, domain; → type vendor_foo, domain;

系統資源 處理標籤擁有權的處理程序

避免使用屬性命名空間來解決衝突問題。目的地： 輕鬆識別平台屬性，並在重新命名或 新增匯出的平台資源，並確認所有供應商資源都具備 自己的前置字串：

物業類型	可接受的前置字元
控制項屬性	ctl.vendor. ctl.start$vendor. ctl.stop$vendor. init.svc.vendor.
可寫入	vendor.
唯讀	ro.vendor. ro.boot. ro.hardware.
永久	persist.vendor.

供應商可以繼續使用來自核心的 ro.boot.* cmdline) 和 ro.hardware.* (明顯的硬體相關屬性)。

init rc 檔案中的所有供應商服務都應有 vendor. 適用於非系統分區 init rc 檔案的服務。類似的規則 已套用至供應商資源的 SELinux 標籤 (vendor_ )。

檔案擁有權

想防止檔案衝突並不容易，因為平台和廠商 政策往往都會為所有檔案系統提供標籤。有別於型別命名 檔案名稱間距不切實際，因為許多檔案都是 核心。為避免發生這類衝突，請遵守檔案系統的命名指引 本節如果是 Android 8.0，請參考以下建議，不需要仰賴技術背景 強制執行。日後，這些建議將由 供應商測試套件 (VTS)。

系統 (/系統)

只有系統映像檔必須為 /system 元件提供標籤 到 file_contexts、service_contexts 等。如果標籤為 /system元件已新增至 /vendor 政策， 可能無法進行只有架構專屬的 OTA 更新。

供應商 (/vendor)

Android 開放原始碼計畫 SELinux 政策已為 vendor 分區的部分加上標籤 平台互動，進而編寫平台的 SELinux 規則 程序以對「vendor」的某些部分進行通話和/或存取 範例：

/vendor路徑	平台提供的標籤	平台程序會因標籤而異
/vendor(/.*)?	vendor_file	架構中的所有 HAL 用戶端、ueventd 等
/vendor/framework(/.*)?	vendor_framework_file	dex2oat、appdomain 等
/vendor/app(/.*)?	vendor_app_file	dex2oat、installd、idmap 等
/vendor/overlay(/.*)	vendor_overlay_file	system_server、zygote、idmap 等

因此，您必須遵循特定規則 (透過 neverallows)，為「vendor」中的其他檔案加上標籤 分區：

• 「vendor_file 」必須是以下目錄內所有檔案的預設標籤： vendor 個分區。根據平台政策，你必須進行這項設定才能存取 直通式 HAL 實作。
• 所有新的 exec_types 已新增至 vendor 分區 透過供應商 SEPolicy 必須含有 vendor_file_type 屬性。這個 就會強制執行
• 為了避免與日後的平台/架構更新發生衝突，請避免加上標籤 vendor 分區中的 exec_types 以外的檔案。
• 所有與 Android 開放原始碼計畫 (AOSP) 識別相同的程序 HAL 的程式庫依附元件，都必須 已標示為「same_process_hal_file.」

Procfs (/proc)

/proc 中的檔案可能只能使用 genfscon 加上標籤 標籤。在 Android 7.0 中， 平台 和供應商 政策使用 genfscon 為 procfs 中的檔案加上標籤。

建議：僅限平台政策標籤 /proc。 如果 vendor 個程序需要存取 /proc 中 目前標有預設標籤 (proc)、廠商政策 不應明確加上標籤，因此應改用通用 proc 類型可新增供應商網域規則。如此一來 進行更新，以便因應未來核心介面 procfs，並視需要明確加上標籤。

Debugfs (/sys/kernel/debug)

「Debugfs」可同時加上「file_contexts」和「 genfscon。Android 7.0 至 Android 10 中，平台和供應商標籤 debugfs。

在 Android 11 中，無法 debugfs 存取或掛接於實際工作環境裝置上裝置製造商 移除 debugfs。

追蹤程式 (/系統/核心/偵錯/追蹤)

「Tracefs」可同時加上「file_contexts」和「 genfscon。Android 7.0 中只有平台標籤 tracefs。

建議：只有平台可以為 tracefs 加上標籤。

Sysfs (/sys)

「/sys」中的檔案可以使用兩個 file_contexts 加上標籤 和 genfscon。在 Android 7.0 中，平台和供應商皆使用 file_contexts和 genfscon，即可為以下位置中的檔案加上標籤 sysfs。

建議：平台可能會為 sysfs 加上標籤 而非裝置專屬的節點否則，只有供應商能夠為檔案加上標籤。

tmpfs (/開發)

/dev 中的檔案可能是以 file_contexts 加上標籤。於 Android 7.0 (平台和供應商標籤檔案)。

建議：供應商只能為以下文件中的檔案加上標籤： /dev/vendor (例如/dev/vendor/foo, /dev/vendor/socket/bar)。

根層級 (/)

/ 中的檔案可能是以 file_contexts 加上標籤。在 Android 中 7.0，平台和供應商標籤檔案。

建議事項：只有系統能為 / 中的檔案加上標籤。

資料 (/data)

系統會結合 file_contexts 和 seapp_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 政策而無法存取 類型。

透過根據屬性來定義政策，我們就能為基礎物件提供 這種類型包含同時包含平台政策和 供應商代碼。適用於所有類型，有效率地建立 attribute-policy，瞭解具體類型。實務上 只有平台之間重疊的政策部分才需要執行這項程序 和供應商，這兩個定義都定義為平台公開政策，並提供相關服務 但這是做為供應商政策的一部分

將公開政策定義為版本化屬性，必須符合兩項政策 相容性目標：

• 確保供應商程式碼在平台更新後仍可正常運作。 將屬性新增至與 並保留存取。
• 淘汰政策的功能。明確達成 將政策組合區分為屬性 則不再受到支援。開發工具 我們會繼續發布新政策，不過 供應商政策，且會在升級時自動移除。

政策可寫性

不必瞭解 Android 8.0 的政策開發過程包含各平台公開的對應資訊 政策類型和屬性已對應「foo」類型 至 foo_vN 屬性，其中 N 是 指定版本vN 對應到 PLATFORM_SEPOLICY_VERSION 建構變數，格式為 MM.NN，其中 MM 對應平台 SDK 編號 NN 是平台專用版本。

公開政策中的屬性並未版本管理，而是會以 API 的形式存在 使用最新的版本平台和供應商政策寫入者仍可繼續寫入 政策。

以 allow source_foo target_bar:class perm; 格式匯出的平台公開政策包含在供應商政策中。過程中 compile 方法，其中包含 則會轉換成 裝置的廠商部分 (如轉換後的通用中級中所示) 語言 (CIL)：

 (allow source_foo_vN target_bar_vN (class (perm)))

由於供應商政策永遠領先平台，因此 較舊版本。然而，平台政策必須知道供應商多遠 同時納入其類型的屬性，並設定 版本屬性

政策差異

在結尾加上 _vN 即可自動建立屬性 如果沒有將屬性對應至不同版本中的類型，每種類型都不會執行任何動作 差異比較。Android 會對應屬性和 對應類型與這些屬性對應的類型這是在上述對應過程中 含有陳述式的檔案，例如 (CIL)：

(typeattributeset foo_vN (foo))

平台升級

以下各節將詳細說明平台升級的情境。

相同類型

如果物件在政策版本中並未變更標籤，就會發生這種情況。 這在來源和目標類型中也是如此，您可以透過 /dev/binder，在所有公司都加上了 binder_device 標籤 版本。轉換政策中的表示：

binder_device_v1 … binder_device_vN

從 v1 → v2 升級時，平台政策必須 包含：

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

在第 1 版對應檔 (CIL) 中：

(typeattributeset binder_device_v1 (binder_device))

在第 2 版對應檔 (CIL)：

(typeattributeset binder_device_v2 (binder_device))

在第 1 版供應商政策 (CIL) 中：

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

在第 2 版供應商政策 (CIL) 中：

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

新類型

當平台新增了類型，就可能發生這種情況 或在政策強化期間加入附註

• 新功能。當類型為物件加上標籤時 和先前不存在 (例如新的服務程序)，供應商程式碼沒有 先前直接與此互動，因此沒有相應的政策。而 對應到類型的屬性，在先前的範例中沒有 屬性 因此不需要在對應的對應檔案中指定 版本。
• 政策強化。如果類型表示政策 新的 type 屬性必須連回屬性鏈結 與先前的範例變更時 /sys/A從 sysfs 到 sysfs_A)。供應商 程式碼參照了一項規則，該規則能讓您存取 sysfs ，將該規則納入新類型的屬性。

從 v1 → v2 升級時，平台政策必須 包含：

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

在第 1 版對應檔 (CIL) 中：

(typeattributeset sysfs_v1 (sysfs sysfs_A))

在第 2 版對應檔 (CIL)：

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

在第 1 版供應商政策 (CIL) 中：

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

在第 2 版供應商政策 (CIL) 中：

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

已移除的類型

這種情況 (很少) 會在類型移除時發生，且當 基礎物件：

• 會保留，但標籤不同。
• 會由平台移除，

在政策放寬期間，系統會移除一個類型，並為其加上該類型標籤 已套用不同的現有標籤這代表的 屬性對應：供應商代碼仍必須能存取 物件視為物件，但系統的其他部分必須現在 就能透過新屬性存取該資源

如果切換後的屬性是新的，那麼重新標籤就是 與新的類型大小寫相同，但使用現有標籤時， 新增舊屬性時，會使其他物件一併加上 以便直接存取基本上，這些模型是由 Google 認為在維護 相容性。

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

範例第 1 版：收合類型 (移除 sysfs_A)

從 v1 → v2 升級時，平台政策必須 包含：

type sysfs; (type sysfs) (in CIL)

在第 1 版對應檔 (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))

在第 2 版對應檔 (CIL)：

(typeattributeset sysfs_v2 (sysfs))

在第 1 版供應商政策 (CIL) 中：

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

在第 2 版供應商政策 (CIL) 中：

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

範例第 2 版：完全移除 (foo type)

從 v1 → v2 升級時，平台政策必須 包含：

# nothing - we got rid of the type

在第 1 版對應檔 (CIL) 中：

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

在第 2 版對應檔 (CIL)：

# nothing - get rid of it

在第 1 版供應商政策 (CIL) 中：

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

在第 2 版供應商政策 (CIL) 中：

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

新增課程/權限

當平台升級加入新的政策元件，就會發生這種情形 不提供舊版資源舉例來說，當 Android 新增 建立了新增、尋找和列出檔案的 servicemanager 物件管理員 權限、想要向 servicemanager 項需要的必要權限 廣告。在 Android 8.0 中，只有平台政策可以新增類別和 授予其要求的權限。

如要允許由供應商政策建立或擴充的所有網域 如要使用新類別而不加以遮蓋，平台政策必須包含 類似下列規則：

allow {domain -coredomain} *:new_class perm;

這甚至可能還需要透過政策允許所有介面存取 (公開政策) 才能確保供應商映像檔取得存取權如果這會導致 安全性政策 (可能與 Servicemanager 相關變更) 表示 系統可能強制升級

已移除課程/權限

當物件管理員遭到移除 (例如 ZygoteConnection 物件管理工具)，且不應造成問題。 物件管理員類別和權限可在政策中保持定義，直到 就不會再使用。做法是加入定義 對應至對應的對應檔案

供應商自訂項目 新/已重新加上標籤的類型

新的供應商類型是供應商政策研擬的核心，因為有需要 描述新的程序、二進位檔、裝置、子系統和儲存的資料。阿斯 因此建立供應商定義的類型至關重要。

由於供應商政策一律是裝置的最舊版本，因此不必 自動將所有供應商類型轉換為政策中的屬性。平台 不仰賴供應商政策中標記的任何項目，因為平台沒有 相關知識但平台會提供屬性 以及容器與具有這些類型標籤的物件互動 (例如 domain、sysfs_type 等)。可讓平台 會持續與這些物件正確互動，所有屬性和類型 必須適當套用，而且可能還需要在 自訂網域 (例如 init)。

Android 9 的屬性變更

升級至 Android 9 的裝置可使用下列屬性，但裝置除外 但在 Android 9 上啟動的應用程式

違規者屬性

Android 9 包含下列網域相關屬性：

• data_between_core_and_vendor_violators。 請務必由此屬性標示所有違反「不共用檔案」規定的網域 vendor 和 coredomains 之間的路徑平台和 廠商程序不應使用磁碟上的檔案進行通訊 (不穩定的 ABI)。 建議：
  • 供應商程式碼應使用 /data/vendor。
  • 系統不應使用 /data/vendor。
• system_executes_vendor_violators。屬性 適用於所有系統網域 (init 和 shell 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 Binder 服務提供的， 。
• hal_omx_hwservice。這是 HwBinder 版本的 mediacodec Binder 服務 (允許存取哪些應用程式)。
• 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 的應用程式應設有 供應商定義的聯盟網域

檔案屬性測試

Android 9 內含建構時間測試，確保所有檔案都在特定 地點都有適當的屬性 (例如 sysfs 必須具有必要的 sysfs_type 屬性)。

平台公開政策

平台公開政策是符合 Android 8.0 的核心核心。 不必維護平台政策的聯集 從第 1 版和第 2 版開始供應商會實施部分平台政策， 包含可用的類型、屬性和規則，適用於這些類型和屬性 這項政策會納入供應商政策的一部分 (例如 vendor_sepolicy.cil)。

供應商產生的政策會自動翻譯類型和規則 轉換為 attribute_vN，這樣所有平台提供的類型 是版本化屬性 (但屬性並未版本化)。平台是 負責將提供的具體類型對應至適當的 屬性確保供應商政策能繼續運作， 中的特定版本。結合 平台公開政策和供應商政策符合 Android 8.0 架構 以及允許獨立平台和供應商建構的模型目標。

對應至屬性鏈結

使用屬性對應至政策版本時，類型會對應到 多個屬性，確保使用者可透過 對應先前類型的屬性

維護向政策寫入者隱藏版本資訊的目標 自動產生版本屬性並指派給 或適當類型在靜態型別的常見案例中，這看起來十分簡單： type_foo 對應至 type_foo_v1。

變更物件標籤變更 (例如 sysfs → sysfs_A 或 mediaserver → audioserver，建立此對應關係時 (如上述範例所示)。平台政策維護人員 必須決定如何在物件的轉換點建立對應， 包括瞭解物件與受指派物件之間的關係 並判斷發生這類情況的時機為了顧及回溯相容性 跨平台管理複雜度，而平台端是唯一的 才有可能發展

版本更新

為簡單起見，Android 平台會在新版本推出時 已剪下版本分支版本如上所述，版本號碼位於 PLATFORM_SEPOLICY_VERSION，其格式為 MM.nn， 其中 MM 對應 SDK 值，nn 是 私人價值， /platform/system/sepolicy. 例如 19.0 代表 Kitkat、21.0 代表 Lollipop 22.0 (適用 Marshmallow) 的 Lollipop-MR1 23.0 24.0 代表 Nougat，25.0 代表 Nougat-MR1， 26.0 代表 Oreo，27.0 代表 Oreo-MR1，以及 28.0 (適用於 Android 9)。 更新不一定是整數。適用對象 舉例來說，如果將 MR 觸角延伸到某個版本，導致必須對 system/sepolicy/public，而非 API 採用，則該原則 版本可能為：vN.1。開發中的版本 分支版本是不可用於運送內的裝置 10000.0。

Android 可能會在更新時淘汰最舊的版本。輸入 淘汰某個版本時，Android 可能會透過供應商收集裝置數量 執行該 Android 版本，且目前仍接收主要平台的政策 更新。如果數字小於特定門檻，則該版本為 已淘汰。

下列項目的效能影響： 多項屬性

如 https://github.com/SELinuxProject/cil/issues/9 所述， 將大量指派給某個類型的屬性會導致效能問題 就會發生這類錯誤。

已確認是 Android 的問題，因此異動 才使用 Android 8.0 版。移除之前在政策中新增的屬性 以及移除未使用的屬性這些變更已解決 以免發生效能迴歸問題

System_ext 公開和產品公開政策

自 Android 11 起，可使用 system_ext 和產品分區 將指定公開類型匯出至供應商分區像平台 供應商會採用自動轉譯為公開政策的類型和規則 版本化屬性 (例如從 type 到 type_N，其中 N 是版本 與供應商分區時採用的平台不同

System_ext 和產品分區採用的平台版本相同時 N，建構系統會產生基本對應檔案 「system_ext/etc/selinux/mapping/N.cil」和 product/etc/selinux/mapping/N.cil，包含識別資訊 type 到 type_N 的對應。供應商可以 透過版本化屬性 type_N 存取 type。

如果您只更新 system_ext 和產品分區，請說出 N 到 N+1 (或之後)， 供應商停留在 N，該供應商可能會無法存取 system_ext 和產品分區類型為了防止服務中斷 system_ext 和產品分區應提供具體的對應檔案 轉換為 type_N 屬性每位合作夥伴 但可以自行維護對應檔案 N擁有 N+1 (或之後版本) 的供應商 system_ext 和產品分區

為此，合作夥伴應採取下列做法：

1. 從「N」複製產生的基本對應檔案 system_ext 和產品劃分 加入原始碼樹狀結構
2. 視需要修改對應檔案。
3. 安裝 對應檔案至 N+1 (或之後版本) system_ext 以及 產品劃分

舉例來說，假設 N system_ext 具有一個公開 類型：foo_type。之後system_ext/etc/selinux/mapping/N.cil 在 N system_ext 分區中，如下所示：

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

如果將 bar_type 新增至 N+1 system_ext，且 如果 bar_type 應對應至 foo_type 「N」供應商「N.cil」可從以下位置更新：

(typeattributeset foo_type_N (foo_type))

到

(typeattributeset foo_type_N (foo_type bar_type))

然後安裝到 N+1 system_ext 的分區。 N 個供應商可以繼續使用 N+1 system_ext 的 foo_type 和 bar_type。

SELinux 結構定義標籤

為了因應平台與供應商的區別 系統會以不同方式建構 SELinux 結構定義檔案，以便分開存放。

檔案內容

Android 8.0 為 file_contexts 推出了下列變更：

• 為了避免裝置在啟動時造成額外的編譯負擔 file_contexts 不再以二進位格式存在。而是 皆為可讀取的規則運算式文字檔案，例如 {property, service}_contexts (7.0 之前的)。
• file_contexts 會分割為兩個檔案：
  • plat_file_contexts
    • Android 平台 file_context 沒有任何 裝置專屬的標籤，除了為 /vendor 個分區，必須精確標示 確保這項政策檔案運作正常
    • 必須位於 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_contexts 英吋 vendor 個分區，並由 init 於 和 file_context 平台都是如此。

房源情境

在 Android 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

服務情境

在 Android 8.0 中，service_contexts 分為下列內容： 檔案：

• plat_service_contexts
  • Android 平台專屬的 service_context： servicemanager。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「不得」存在。這是因為 vendor 和 system 之間的所有互動 這些程序必須執行 hwservicemanager/hwbinder。
• plat_hwservice_contexts
  • Android 平台 hwservice_context： 沒有裝置專屬標籤的 hwservicemanager。
  • 必須位於 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 在一開始就由 hwservicemanager 載入 plat_service_contexts。
• vndservice_contexts
  • 裝置專屬 service_context： 結合 vndservicemanager 在指向的目錄中找到 vndservice_contexts BOARD_SEPOLICY_DIRS儲存在裝置的 Boardconfig.mk。
  • 這個檔案必須位於 vendor 分區： /vendor/etc/selinux/vndservice_contexts並由以下使用者載入： vndservicemanager。

Seapp 結構定義

在 Android 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 權限

在 Android 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/.