In diesem Artikel wird erläutert, wie die SELinux-Richtlinie erstellt wird. Die SELinux-Richtlinie wird aus der Kombination der AOSP-Kernrichtlinie (Plattform) und der gerätespezifischen Richtlinie (Anbieter) erstellt. Der SELinux-Richtlinien-Build-Flow für Android 4.4 bis Android 7.0 führte alle Sepolicy-Fragmente zusammen und generierte dann monolithische Dateien im Stammverzeichnis. Dies bedeutete, dass SoC-Anbieter und ODM-Hersteller bei jeder Änderung der Richtlinie boot.img
(für Nicht-A/B-Geräte) oder system.img
(für A/B-Geräte) änderten.
In Android 8.0 und höher werden Plattform- und Anbieterrichtlinien separat erstellt. SOCs und OEMs können ihre Teile der Richtlinie aktualisieren, ihre Images erstellen (z. vendor.img
und boot.img
) und diese Images dann unabhängig von Plattformaktualisierungen aktualisieren.
Da modularisierte SELinux-Richtliniendateien jedoch auf /vendor
Partitionen gespeichert werden, muss der init
Prozess die System- und Herstellerpartitionen früher mounten, damit er SELinux-Dateien von diesen Partitionen lesen und sie mit den SELinux-Kerndateien im Systemverzeichnis zusammenführen kann (bevor er sie in lädt). der Kernel).
Quelldaten
Die Logik zum Erstellen von SELinux befindet sich in diesen Dateien:
-
external/selinux
: Externes SELinux-Projekt, das zum Erstellen von HOST-Befehlszeilendienstprogrammen zum Kompilieren von SELinux-Richtlinien und -Labels verwendet wird.-
external/selinux/libselinux
: Android verwendet nur eine Teilmenge des externenlibselinux
Projekts zusammen mit einigen Android-spezifischen Anpassungen. Einzelheiten finden Sie unterexternal/selinux/README.android
. -
external/selinux/libsepol
: -
external/selinux/checkpolicy
: SELinux-Richtlinien-Compiler (ausführbare Hostdateien:checkpolicy
,checkmodule
unddispol
). Hängt vonlibsepol
ab.
-
-
system/sepolicy
: Kernrichtlinienkonfigurationen für Android SELinux, einschließlich Kontexten und Richtliniendateien. Hier finden Sie auch die wichtigste Sepolicy-Build-Logik (system/sepolicy/Android.mk
).
Weitere Einzelheiten zu den Dateien finden Sie unter system/sepolicy
Implementing SELinux .
Android 7.0 und früher
In diesem Abschnitt wird erläutert, wie die SELinux-Richtlinie in Android 7.x und früher erstellt wird.
Erstellen einer SELinux-Richtlinie
Die SELinux-Richtlinie wird durch die Kombination der AOSP-Kernrichtlinie mit gerätespezifischen Anpassungen erstellt. Die kombinierte Richtlinie wird dann an den Richtlinien-Compiler und verschiedene Prüfer übergeben. Die gerätespezifische Anpassung erfolgt über die Variable BOARD_SEPOLICY_DIRS
, die in der gerätespezifischen Datei Boardconfig.mk
definiert ist. Diese globale Build-Variable enthält eine Liste von Verzeichnissen, die die Reihenfolge angeben, in der nach zusätzlichen Richtliniendateien gesucht werden soll.
Beispielsweise könnten ein SoC-Anbieter und ein ODM jeweils ein Verzeichnis hinzufügen, eines für die SoC-spezifischen Einstellungen und ein weiteres für gerätespezifische Einstellungen, um die endgültigen SELinux-Konfigurationen für ein bestimmtes Gerät zu generieren:
-
BOARD_SEPOLICY_DIRS += device/ SOC /common/sepolicy
-
BOARD_SEPOLICY_DIRS += device/ SoC / DEVICE /sepolicy
Der Inhalt der file_contexts-Dateien in system/sepolicy
und BOARD_SEPOLICY_DIRS
wird verkettet, um die file_contexts.bin
auf dem Gerät zu generieren:
![Dieses Bild zeigt die SELinux-Build-Logik für Android 7.x.](https://source.android.google.cn/static/docs/security/features/selinux/images/n-selinux-build-logic.png?authuser=6&hl=de)
Die sepolicy
Datei besteht aus mehreren Quelldateien:
- Die Nur-Text
policy.conf
wird durch Verketten vonsecurity_classes
,initial_sids
,*.te
-Dateien,genfs_contexts
undport_contexts
in dieser Reihenfolge generiert. - Der Inhalt jeder Datei (z. B.
security_classes
) ist die Verkettung der Dateien mit demselben Namen untersystem/sepolicy/
undBOARDS_SEPOLICY_DIRS
. - Die
policy.conf
wird zur Syntaxprüfung an den SELinux-Compiler gesendet und alssepolicy
auf dem Gerät in ein Binärformat kompiliert.Figur 2 . SELinux-Richtliniendatei
SELinux-Dateien
Nach dem Kompilieren enthalten Android-Geräte mit 7.x und früher normalerweise die folgenden SELinux-bezogenen Dateien:
-
selinux_version
- sepolicy: Binärausgabe nach dem Kombinieren von Richtliniendateien (z. B.
security_classes
,initial_sids
und*.te
) -
file_contexts
-
property_contexts
-
seapp_contexts
-
service_contexts
-
system/etc/mac_permissions.xml
Weitere Einzelheiten finden Sie unter Implementieren von SELinux .
SELinux-Initialisierung
Wenn das System hochfährt, befindet sich SELinux im permissiven Modus (und nicht im erzwingenden Modus). Der Init-Prozess führt die folgenden Aufgaben aus:
- Lädt
sepolicy
Dateien von der Ramdisk über/sys/fs/selinux/load
in den Kernel. - Schaltet SELinux in den Erzwingungsmodus.
- Führt
re-exec()
aus, um die SELinux-Domänenregel auf sich selbst anzuwenden.
Um die Startzeit zu verkürzen, führen Sie so schnell wie möglich re-exec()
für den init
Prozess aus.
Android 8.0 und höher
In Android 8.0 ist die SELinux-Richtlinie in Plattform- und Anbieterkomponenten aufgeteilt, um unabhängige Plattform-/Anbieterrichtlinienaktualisierungen zu ermöglichen und gleichzeitig die Kompatibilität aufrechtzuerhalten.
Die Plattform-Separatrichtlinie ist weiter in einen privaten und einen öffentlichen Teil der Plattform unterteilt, um bestimmte Typen und Attribute an Anbieter-Richtlinienautoren zu exportieren. Es wird garantiert, dass die öffentlichen Typen/Attribute der Plattform als stabile APIs für eine bestimmte Plattformversion beibehalten werden. Die Kompatibilität mit früheren öffentlichen Typen/Attributen der Plattform kann für mehrere Versionen mithilfe von Plattformzuordnungsdateien gewährleistet werden.
Öffentliche Politik der Plattform
Die Plattform public sepolicy umfasst alles, was unter system/sepolicy/public
definiert ist. Die Plattform kann davon ausgehen, dass es sich bei den in der öffentlichen Richtlinie definierten Typen und Attributen um stabile APIs für eine bestimmte Plattformversion handelt. Dies ist der Teil der Sepolicy, der von der Plattform exportiert wird, auf der Entwickler von Anbieterrichtlinien (d. h. Geräterichtlinien) zusätzliche gerätespezifische Richtlinien schreiben können.
Typen werden entsprechend der Version der Richtlinie versioniert, gegen die Herstellerdateien geschrieben werden, definiert durch die Build-Variable PLATFORM_SEPOLICY_VERSION
. Die versionierte öffentliche Richtlinie wird dann in die Anbieterrichtlinie und (in ihrer ursprünglichen Form) in die Plattformrichtlinie aufgenommen. Somit umfasst die endgültige Richtlinie die private Plattformrichtlinie, die öffentliche Sep-Richtlinie der aktuellen Plattform, die gerätespezifische Richtlinie und die versionierte öffentliche Richtlinie, die der Plattformversion entspricht, für die die Geräterichtlinie geschrieben wurde.
Private Separierung der Plattform
Die private Sepolicy der Plattform umfasst alles, was unter /system/sepolicy/private
definiert ist. Dieser Teil der Richtlinie bildet plattformspezifische Typen, Berechtigungen und Attribute, die für die Plattformfunktionalität erforderlich sind. Diese werden nicht an die Ersteller der vendor/device
exportiert. Nicht-Plattform-Richtlinienautoren dürfen ihre Richtlinienerweiterungen nicht auf der Grundlage von Typen/Attributen/Regeln schreiben, die in der privaten Sepolicy der Plattform definiert sind. Darüber hinaus dürfen diese Regeln im Rahmen eines reinen Framework-Updates geändert werden oder verschwinden.
Private Plattformzuordnung
Die private Plattformzuordnung umfasst Richtlinienanweisungen, die die in der öffentlichen Plattformrichtlinie der vorherigen Plattformversionen offengelegten Attribute den konkreten Typen zuordnen, die in der aktuellen öffentlichen Plattformrichtlinie verwendet werden. Dadurch wird sichergestellt, dass die Anbieterrichtlinie, die auf der Grundlage der öffentlichen Plattformattribute der vorherigen öffentlichen Plattform-Sepolicy-Version(en) geschrieben wurde, weiterhin funktioniert. Die Versionierung basiert auf der Build-Variable PLATFORM_SEPOLICY_VERSION
, die in AOSP für eine bestimmte Plattformversion festgelegt ist. Für jede vorherige Plattformversion, von der aus diese Plattform die Herstellerrichtlinien akzeptieren soll, ist eine separate Zuordnungsdatei vorhanden. Weitere Einzelheiten finden Sie unter Kompatibilität .
Android 11 und höher
system_ext und Produkttrennrichtlinie
In Android 11 werden die system_ext-Richtlinie und die Produktrichtlinie hinzugefügt. Wie die Plattform-Sepolicy sind auch die system_ext-Richtlinie und die Produktrichtlinie in öffentliche Richtlinien und private Richtlinien unterteilt.
Die öffentliche Ordnung wird an den Anbieter exportiert. Typen und Attribute werden zu einer stabilen API, und die Anbieterrichtlinie kann auf Typen und Attribute in der öffentlichen Richtlinie verweisen. Typen werden gemäß PLATFORM_SEPOLICY_VERSION
versioniert und die versionierte Richtlinie ist in der Anbieterrichtlinie enthalten. Die ursprüngliche Richtlinie ist sowohl in system_ext als auch in der Produktpartition enthalten.
Die private Richtlinie enthält Nur-System_Ext- und Nur-Produkt-Typen, Berechtigungen und Attribute, die für die Funktionalität von System_Ext- und Produktpartitionen erforderlich sind. Private Richtlinien sind für den Anbieter unsichtbar, was bedeutet, dass diese Regeln intern sind und geändert werden dürfen.
system_ext und Produktzuordnung
system_ext und product dürfen ihre designierten öffentlichen Typen an den Anbieter exportieren. Die Verantwortung für die Aufrechterhaltung der Kompatibilität liegt jedoch bei jedem Partner. Aus Kompatibilitätsgründen können Partner ihre eigenen Zuordnungsdateien bereitstellen, die die versionierten Attribute früherer Versionen konkreten Typen zuordnen, die in der aktuellen öffentlichen Sepolicy verwendet werden.
- Um eine Zuordnungsdatei für system_ext zu installieren, platzieren Sie eine CIL-Datei mit den gewünschten Zuordnungsinformationen in
{SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS}/compat/{ver}/{ver}.cil
und fügen Sie dannsystem_ext_{ver}.cil
zuPRODUCT_PACKAGES
hinzu. - Um eine Zuordnungsdatei für das Produkt zu installieren, platzieren Sie eine CIL-Datei mit den gewünschten Zuordnungsinformationen in
{PRODUCT_PRIVATE_SEPOLICY_DIRS}/compat/{ver}/{ver}.cil
und fügen Sie dannproduct_{ver}.cil
zuPRODUCT_PACKAGES
hinzu. Sehen Sie sich ein Beispiel an, das eine Zuordnungsdatei der Produktpartition des Redbull-Geräts hinzufügt. - Konvertieren von Richtlinien in das SELinux Common Intermediate Language (CIL)-Format, insbesondere:
- öffentliche Plattformrichtlinie (System + system_ext + Produkt)
- kombinierte private + öffentliche Politik
- public + Vendor und
BOARD_SEPOLICY_DIRS
-Richtlinie
- Versionierung der von der Öffentlichkeit bereitgestellten Richtlinie als Teil der Anbieterrichtlinie. Dies geschieht durch Verwendung der erstellten öffentlichen CIL-Richtlinie, um die kombinierte Richtlinie aus Öffentlichkeit, Anbieter und
BOARD_SEPOLICY_DIRS
darüber zu informieren, welche Teile in Attribute umgewandelt werden müssen, die mit der Plattformrichtlinie verknüpft werden. - Erstellen einer Zuordnungsdatei, die die Plattform- und Anbieterteile verknüpft. Dabei werden zunächst nur die Typen aus der öffentlichen Richtlinie mit den entsprechenden Attributen in der Anbieterrichtlinie verknüpft; Später wird es auch die Grundlage für die Datei bilden, die in zukünftigen Plattformversionen verwaltet wird, und so die Kompatibilität mit den Herstellerrichtlinien für diese Plattformversion ermöglichen.
- Kombinieren von Richtliniendateien (beschreiben Sie sowohl geräteinterne als auch vorkompilierte Lösungen).
- Kombinieren Sie Mapping-, Plattform- und Anbieterrichtlinien.
- Kompilieren Sie die Ausgabe-Binärrichtliniendatei.
- Sowohl
/system/etc/selinux/plat_sepolicy_and_mapping.sha256
als auch/{partition}/etc/selinux/precompiled_sepolicy.plat_sepolicy_and_mapping.sha256
existieren und sind identisch. - Sowohl
/system_ext/etc/selinux/system_ext_sepolicy_and_mapping.sha256
als auch/{partition}/etc/selinux/precompiled_sepolicy.system_ext_sepolicy_and_mapping.sha256
existieren nicht. Oder beide existieren und sind identisch. - Sowohl
/product/etc/selinux/product_sepolicy_and_mapping.sha256
als auch/{partition}/etc/selinux/precompiled_sepolicy.product_sepolicy_and_mapping.sha256
existieren nicht. Oder beide existieren und sind identisch.
Erstellen einer SELinux-Richtlinie
Die SELinux-Richtlinie in Android 8.0 wird durch die Kombination von Teilen aus /system
und /vendor
erstellt. Die Logik für die entsprechende Einrichtung befindet sich in /platform/system/sepolicy/Android.mk
.
Die Richtlinie ist an den folgenden Orten vorhanden:
Standort | Enthält |
---|---|
system/sepolicy/public | Die Sepolicy-API der Plattform |
system/sepolicy/private | Details zur Plattformimplementierung (Anbieter können dies ignorieren) |
system/sepolicy/vendor | Richtlinien- und Kontextdateien, die Anbieter verwenden können (Anbieter können diese bei Bedarf ignorieren) |
BOARD_SEPOLICY_DIRS | Anbieter-Separatpolitik |
BOARD_ODM_SEPOLICY_DIRS (Android 9 und höher) | ODM-Separatpolitik |
SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS (Android 11 und höher) | Sepolicy-API von System_ext |
SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS (Android 11 und höher) | Details zur System_ext-Implementierung (Anbieter können sie ignorieren) |
PRODUCT_PUBLIC_SEPOLICY_DIRS (Android 11 und höher) | Sepolicy-API des Produkts |
PRODUCT_PRIVATE_SEPOLICY_DIRS (Android 11 und höher) | Details zur Produktimplementierung (Anbieter können dies ignorieren) |
Das Build-System übernimmt diese Richtlinie und erstellt System-, system_ext-, Produkt-, Anbieter- und ODM-Richtlinienkomponenten auf der entsprechenden Partition. Zu den Schritten gehören:
Vorkompilierte SELinux-Richtlinie
Bevor init
SELinux einschaltet, sammelt init
alle CIL-Dateien von Partitionen ( system
, system_ext
, product
, vendor
und odm
) und kompiliert sie in die Binärrichtlinie, das Format, das in den Kernel geladen werden kann. Da die Kompilierung einige Zeit in Anspruch nimmt (normalerweise 1–2 Sekunden), werden die CIL-Dateien zur Erstellungszeit vorkompiliert und zusammen mit den sha256-Hashes entweder unter /vendor/etc/selinux/precompiled_sepolicy
oder /odm/etc/selinux/precompiled_sepolicy
abgelegt der eingegebenen CIL-Dateien. Zur Laufzeit prüft init
, ob eine der Richtliniendateien aktualisiert wurde, indem es die Hashes vergleicht. Wenn sich nichts geändert hat, lädt init
die vorkompilierte Richtlinie. Wenn nicht, kompiliert init
es im laufenden Betrieb und verwendet es anstelle des vorkompilierten.
Genauer gesagt wird eine vorkompilierte Richtlinie verwendet, wenn alle der folgenden Bedingungen erfüllt sind. Hier stellt {partition}
die Partition dar, in der die vorkompilierte Richtlinie vorhanden ist: entweder vendor
oder odm
.
Wenn sich einer davon unterscheidet, greift init
auf den Kompilierungspfad auf dem Gerät zurück. Weitere Informationen finden Sie system/core/init/selinux.cpp
.