Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

政策相容性

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

基於Treble的SELinux策略設計考慮了平台策略和供應商策略之間的二進制區別。如果供應商分區生成依賴項(例如platform < vendor < oem ,則該方案將變得更加複雜。

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

  • 對於版本控制,導出的平台公共策略將被寫為attribute
  • 為了便於編寫策略,在策略構建過程中,將導出的類型轉換為版本化的屬性 。公共類型也可以直接用於標記供應商上下文文件提供的決策。

Android維護平台策略中導出的具體類型與每個平台版本的相應版本屬性之間的映射 。這樣可以確保在用類型標記對象時,它不會破壞以前版本中平台公共策略所保證的行為。通過保持每個平台版本的映射文件為最新來維護此映射,該映射文件保留公共策略中導出的每種類型的屬性成員資格信息。

對象所有權和標籤

在Android 8.0及更高版本中自定義策略時,必須為每個對像明確定義所有權,以使平台和供應商策略分開。例如,如果供應商標記了/dev/foo ,然後平台在隨後的OTA中標記了/dev/foo ,則將出現未定義的行為。對於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.* (與硬件相關的明顯屬性)。

init 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 框架, ueventd等中的所有HAL客戶端
/vendor/framework(/. * )? vendor_framework_file dex2oatappdomain等。
/vendor/app(/. * )? vendor_app_file dex2oatinstalldidmap等。
/vendor/overlay(/. * ) vendor_overlay_file system_serverzygoteidmap等。

因此,在vendor分區中標記其他文件時,必須遵循特定規則(通過neverallows強制執行):

  • vendor_file必須是vendor分區中所有文件的默認標籤。平台策略要求此訪問通過HAL的實現。
  • 通過供應商exec_types添加到vendor分區中的所有新exec_types必須具有vendor_file_type屬性。這是通過Neverallows強制執行的。
  • 為避免與將來的平台/框架更新發生衝突,請避免在vendor分區中標記exec_types以外的文件。
  • AOSP標識的相同進程HAL的所有庫依賴項都必須標記為same_process_hal_file.

操作(/ proc)

/proc文件可以僅使用genfscon標籤進行標籤。在Android 7.0中, 平台供應商策略都使用genfsconprocfs標記文件。

建議:僅平台策略標籤/proc 。如果vendor進程需要訪問當前使用默認標籤( proc )標記的/proc中的文件,則供應商策略不應顯式標記它們,而應使用通用proc類型為供應商域添加規則。這允許平台更新適應通過procfs公開的將來的內核接口,並根據需要明確標記它們。

Debugfs(/ sys / kernel / debug)

Debugfs可以在file_contextsgenfscon標記。在Android 7.0到Android 10中,平台和供應商都將標籤debugfs

在Android 11中,無法訪問debugfs或將debugfs安裝在生產設備上。設備製造商應刪除debugfs

Tracefs(/ sys /內核/調試/跟踪)

Tracefs可以在file_contextsgenfscon標記。在Android 7.0中,僅平台標記了tracefs

建議:僅平台可以標記tracefs

Sysfs(/ sys)

/sys文件可以同時使用file_contextsgenfscon進行標記。在Android 7.0中,平台和供應商都使用file_contextsgenfscon標記sysfs文件。

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

tmpfs(/ dev)

/dev文件可以在file_contexts標記。在Android 7.0中,平台標籤和供應商標籤文件都在此處。

建議:供應商只能標記/dev/vendor文件(例如/dev/vendor/foo/dev/vendor/socket/bar )。

Rootfs(/)

/文件可以在file_contexts標記。在Android 7.0中,平台標籤和供應商標籤文件都在此處。

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

數據(/數據)

通過file_contextsseapp_contexts的組合來標記數據。

建議:禁止在/data/vendor之外標記/data/vendor 。只有平台可以標記/data其他部分。

兼容性屬性

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

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

76

之所以可行,是因為該策略是用所有類型的知識編寫的。但是,如果供應商策略和平台策略使用特定類型,並且特定對象的標籤僅在其中一個策略中發生更改,則另一個可能包含先前依賴於獲得或失去訪問權限的策略。例如:

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

儘管供應商策略將保持不變,但由於缺少針對新sysfs_A類型的策略, v_domain將失去訪問權限。

通過根據屬性定義策略,我們可以為基礎對象提供一種類型,該類型的屬性與平台和供應商代碼的策略相對應。可以對所有類型執行此操作,以有效地創建其中永遠不使用具體類型的屬性策略 。實際上,僅對於平台和供應商之間重疊的策略部分才需要這樣做,這些部分已定義並作為平台公共策略提供 ,並作為供應商策略的一部分而構建。

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

  • 確保供應商代碼在平台更新後繼續工作 。通過為與依賴供應商代碼的對象相對應的對象的具體類型添加屬性來實現,從而保留訪問權限。
  • 否決政策的能力 。通過將策略集明確劃分為屬性即可實現,只要不再支持與之對應的版本,就可以將其刪除。知道舊的策略仍然存在於供應商策略中,並且可以在升級時自動刪除,因此可以繼續在平台中進行開發。

政策可寫性

為了達到不需要了解特定版本更改以進行策略開發的目標,Android 8.0包含了平台公共策略類型及其屬性之間的映射。類型foo映射到屬性foo_v N ,其中N是目標版本。 vN對應於PLATFORM_SEPOLICY_VERSION構建變量,格式為MM.NN ,其中MM對應於平台SDK編號,而NN是特定於平台Sepolicy的版本。

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

平台公共策略導出為allow source_foo target_bar: class perm ;包含在供應商政策中。在編譯期間(包括相應的版本),它將轉換為將轉到設備供應商部分的策略(以轉換後的通用中間語言(CIL)顯示):

 (allow source_foo_vN target_bar_vN (class (perm)))

由於供應商策略永遠不在平台之前,因此不應與以前的版本有關。但是,平台策略將需要知道供應商策略的溯源,包含其類型的屬性以及設置與版本屬性相對應的策略。

政策差異

如果沒有在版本差異之間將屬性映射到類型,則通過在每個類型的末尾添加_v N來自動創建屬性不會執行任何操作。 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 …)

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

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

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

  • 新功能 。當類型標記以前不存在的對象(例如新服務過程)時,供應商代碼先前未直接與其交互,因此不存在相應的策略。與該類型對應的新屬性在先前版本中沒有屬性,因此不需要在映射文件中針對該版本的條目。
  • 政策強化 。當類型表示策略強化時,新的type屬性必須鏈接回與上一個屬性對應的屬性鏈(類似於前面的示例,將/sys/Asysfs更改為sysfs_A )。供應商代碼依賴於啟用對sysfs訪問的規則,並且需要將該規則包括為新類型的屬性。

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

第903章

在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 …)

在第2版供應商政策(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 …)

在第2版供應商政策(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 …)

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

194
新班/許可

當平台升級引入了以前版本中不存在的新策略組件時,就會發生這種情況。例如,當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_hwservicesurfaceflinger Binder服務也提供了這些操作,允許訪問這些應用。
  • hal_omx_hwservice 。這是mediacodec Binder服務的HwBinder版本,允許訪問這些應用。
  • 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域。

文件屬性測試

Android 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類的對象標籤更改,創建此映射並audioserver (在上面的示例中進行了描述)。平台策略維護者必須確定如何在對象的過渡點創建映射,這需要了解對象及其分配的標籤之間的關係,並確定何時發生。為了向後兼容,這種複雜性需要在平台端進行管理,這是唯一可以更新的分區。

版本更新

為簡單起見,當剪切新的發行分支時,Android平台會發行Sepolicy版本。如上所述,版本號包含在PLATFORM_SEPOLICY_VERSION中,格式為MM.nn ,其中MM對應於SDK值,而nn是在/platform/system/sepolicy.維護的私有值/platform/system/sepolicy.例如,Kitkat 19.0 ,Lollipop 21.0 ,Lollipop-MR1 22.0 ,棉花糖23.0 ,牛軋糖24.0 ,Nougat-MR1 25.0 ,Oreo 26.0 ,Oreo-MR1 27.0和Android 9 28.0 。總是整數。例如,如果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上下文標籤

為了支持平台和供應商分隔之間的區別,系統以不同的方式構建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 system分區中,並由init在開始時與供應商file_context一起加載。
    • vendor_file_contexts
      • 設備特定file_context結合內置file_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
      • 必須安裝在/vendor/etc/selinux/vendor_file_contexts vendor分區中的/vendor/etc/selinux/vendor_file_contexts ,並由init與平台file_context一起在開始時加載。

屬性上下文

在Android 8.0中, property_contexts分為兩個文件:

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

服務內容

在Android 8.0中, service_contexts在以下文件之間分割:

  • plat_service_contexts
    • 特定於Android平台的servicemanager service_contextservice_context沒有設備特定的標籤。
    • 必須駐留在/system/etc/selinux/plat_service_contexts system分區中,並在開始時由servicemanager與供應商service_contexts一起加載。
  • vendor_service_contexts
    • 設備特定service_context結合內置service_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須駐留在/vendor/etc/selinux/vendor_service_contexts vendor分區中,並在開始時由servicemanager與平台service_contexts一起加載。
    • 儘管servicemanager在引導時會查找此文件,但對於完全兼容的TREBLE設備,絕對不能存在vendor_service_contexts 。這是因為vendorsystem進程之間的所有交互都必須通過hwservicemanager / hwbinder
  • plat_hwservice_contexts
    • 沒有特定於設備的標籤的hwservicemanager Android平台hwservice_context
    • 必須駐留在/system/etc/selinux/plat_hwservice_contexts system分區中,並在開始時由hwservicemanagervendor_hwservice_contexts一起vendor_hwservice_contexts
  • vendor_hwservice_contexts
    • 設備特定hwservice_context結合內置hwservice_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk文件。
    • 必須位於/vendor/etc/selinux/vendor_hwservice_contexts vendor分區中,並由hwservicemanager在開始時與plat_service_contexts一起plat_service_contexts
  • vndservice_contexts
    • 設備特定service_contextvndservicemanager結合內置vndservice_contexts發現,在目錄由指向BOARD_SEPOLICY_DIRS在設備的Boardconfig.mk
    • 該文件必須位於/vendor/etc/selinux/vndservice_contexts vendor分區中,並在開始時由vndservicemanager加載。

Seapp上下文

在Android 8.0中, seapp_contexts分為兩個文件:

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

MAC權限

在Android 8.0中, mac_permissions.xml分為兩個文件:

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