Richtlinienkompatibilität

In diesem Artikel wird beschrieben, wie Android die Richtlinienkompatibilitätsprobleme mit Plattform-OTAs handhabt, bei denen sich die SELinux-Einstellungen der neuen Plattform von den SELinux-Einstellungen des alten Anbieters unterscheiden können.

Treble-basiertes SELinux - Policy - Design hält eine binäre Unterscheidung zwischen Plattform und Lieferantenpolitik; die Regelung wird komplizierter , wenn Anbieter Partitionen Abhängigkeiten erzeugen, wie platform < vendor < oem .

In Android 8.0 und höher ist die globale SELinux-Richtlinie in private und öffentliche Komponenten unterteilt. Öffentliche Komponenten bestehen aus der Richtlinie und der zugehörigen Infrastruktur, die für eine Plattformversion garantiert verfügbar sind. Diese Richtlinie wird den Autoren von Anbieterrichtlinien zur Verfügung gestellt, damit Anbieter eine Anbieterrichtliniendatei erstellen können, die in Kombination mit der von der Plattform bereitgestellten Richtlinie zu einer voll funktionsfähigen Richtlinie für ein Gerät führt.

  • Für die Versionierung, wird die exportierte plattform öffentliche Ordnung als Attribut geschrieben werden.
  • Zur Vereinfachung der Politik schreiben, werden exportiert Arten in versioniert Attribute als Teil der Politik Build - Prozess transformiert. Öffentliche Typen können auch direkt in Kennzeichnungsentscheidungen verwendet werden, die von Anbieterkontextdateien bereitgestellt werden.

Android verwaltet eine Zuordnung zwischen exportierten konkreten Typen in Plattformpolitik und die entsprechenden versioniert Attribute für jede Plattform - Version. Dadurch wird sichergestellt, dass Objekte, die mit einem Typ gekennzeichnet sind, das Verhalten nicht unterbrechen, das durch die öffentliche Plattformrichtlinie in einer früheren Version garantiert wurde. Diese Zuordnung wird erreicht , indem eine Zuordnungsdatei up-to-date für beibehalten jede Plattform Version , die in der öffentlichen Politik für jeden auszuführende Attribut Mitgliedschaftsinformationen hält.

Objekteigentum und Kennzeichnung

Beim Anpassen der Richtlinie in Android 8.0 und höher muss die Eigentumsrechte für jedes Objekt klar definiert sein, um Plattform- und Anbieterrichtlinie getrennt zu halten. Zum Beispiel, wenn die Verkäufer Etikett /dev/foo und die Plattform dann Etikett /dev/foo in einem nachfolgenden OTA, wird es nicht definiertes Verhalten sein. Bei SELinux manifestiert sich dies als Kennzeichnungskollision. Der Geräteknoten kann nur ein einzelnes Etikett haben, das sich auf das zuletzt angewendete Etikett auflöst. Als Ergebnis:

  • Prozesse , die Notwendigkeit , den Zugang zum erfolglos angewandt Label wird Zugriff auf die Ressource verlieren.
  • Prozesse , die Verstärkung Zugriff auf die Datei brechen können , weil der falsche Geräteknoten erstellt wurde.

Systemeigenschaften können auch Namenskollisionen verursachen, die zu undefiniertem Verhalten auf dem System (sowie zur SELinux-Beschriftung) führen können. Kollisionen zwischen Plattform- und Anbieterlabels können bei jedem Objekt auftreten, das über ein SELinux-Label verfügt, einschließlich Eigenschaften, Dienste, Prozesse, Dateien und Sockets. Um diese Probleme zu vermeiden, definieren Sie klar den Besitz dieser Objekte.

Zusätzlich zu Label-Kollisionen können auch SELinux-Typ-/Attributnamen kollidieren. Eine Typ-/Attributnamenskollision führt immer zu einem Richtlinien-Compiler-Fehler.

Namespace für Typ/Attribute

SELinux lässt nicht mehrere Deklarationen desselben Typs/Attributs zu. Richtlinien mit doppelten Deklarationen können nicht kompiliert werden. Art und Attributnamen Kollisionen, alle Lieferantenerklärungen vermeiden sollten Namespaces werden mit Start np_ .

type foo, domain; → type np_foo, domain;

Eigentum an Systemeigenschaft und Prozesskennzeichnung

Das Vermeiden von Beschriftungskollisionen wird am besten mithilfe von Eigenschafts-Namespaces gelöst. Um Plattformeigenschaften einfach zu identifizieren und Namenskonflikte beim Umbenennen oder Hinzufügen exportierter Plattformeigenschaften zu vermeiden, stellen Sie sicher, dass alle Anbietereigenschaften ihre eigenen Präfixe haben:

Art der Immobilie Akzeptable Präfixe
lese- und beschreibbar vendor.
schreibgeschützt ro.vendor.
ro.boot.
ro.hardware.
hartnäckig persist.vendor.

Anbieter können weiterhin verwenden ro.boot.* (Die vom Kernel cmdline kommt) und ro.hardware.* (Eine offensichtliche Zusammenhang mit der Hardware - Eigenschaft).

Alle der Verkäufer Dienste in init rc - Dateien haben sollten vendor. für Dienste in init rc-Dateien von Nicht-Systempartitionen. Ähnliche Regeln sind für die Anbieter Eigenschaften (auf die SELinux - Etikett aufgebracht vendor_ für die Lieferanten Eigenschaften).

Dateieigentum

Das Verhindern von Kollisionen für Dateien ist eine Herausforderung, da sowohl die Plattform- als auch die Anbieterrichtlinie üblicherweise Labels für alle Dateisysteme bereitstellen. Im Gegensatz zur Typbenennung ist die Namensteilung von Dateien nicht praktikabel, da viele von ihnen vom Kernel erstellt werden. Um diese Kollisionen zu vermeiden, befolgen Sie die Hinweise zur Benennung von Dateisystemen in diesem Abschnitt. Für Android 8.0 sind dies Empfehlungen ohne technische Durchsetzung. In Zukunft werden diese Empfehlungen durch die erzwungen werden Vendor Test Suite (VTS).

System (/system)

Nur die Systemabbild - Etiketten für sorgen müssen /system durch file_contexts , service_contexts usw. Wenn Etiketten für /system in hinzugefügt /vendor ein gerüst nur OTA - Update kann nicht möglich sein.

Lieferant (/Lieferant)

Die AOSP SELinux - Policy - Etiketten bereits Teile der vendor - Partition mit der Plattform interagiert, die SELinux - Regeln für Plattform Prozesse ermöglicht das Schreiben zu können und / oder den Zugang Teile sprechen vendor Partition. Beispiele:

/vendor Von der Plattform bereitgestelltes Etikett Plattformprozesse je nach Label
/vendor(/. * )? vendor_file Alle HAL Kunden im Rahmen, ueventd usw.
/vendor/framework(/. * )? vendor_framework_file dex2oat , appdomain usw.
/vendor/app(/. * )? vendor_app_file dex2oat , installd , idmap usw.
/vendor/overlay(/. * ) vendor_overlay_file system_server , zygote , idmap usw.

Als Ergebnis müssen bestimmte Regeln beachtet werden (durch erzwungene neverallows ) , wenn zusätzliche Dateien in Beschriftung vendor Partition:

  • vendor_file muss die Standardbezeichnung für alle Dateien in seinem vendor Partition. Die Plattformrichtlinie erfordert dies, um auf Passthrough-HAL-Implementierungen zuzugreifen.
  • Alle neuen exec_types in hinzugefügt vendor Partition durch Anbieter SEPolicy muss vendor_file_type Attribut. Dies wird durch Neverallows erzwungen.
  • Um Konflikte zu vermeiden mit zukünftiger Plattform / Rahmen Updates vermeiden Kennzeichnung anderen Dateien als exec_types in vendor - Partition.
  • Alle Bibliotheksabhängigkeiten für AOSP identifizierten gleichen Prozess HALs müssen gekennzeichnet werden same_process_hal_file.

Procfs (/proc)

Dateien in /proc können nur die Verwendung markiert werden genfscon Label. In Android 7.0, sowohl die Plattform und Anbieter - Richtlinie verwendet genfscon zu Etikettendateien in procfs .

Empfehlung: Nur Plattformrichtlinien Etiketten /proc . Wenn vendor Zugriff auf Dateien müssen in /proc , die derzeit mit dem Standard - Etikett (gekennzeichnet sind proc ), sollten Anbieter Politik nicht explizit kennzeichnen und sollten stattdessen die allgemeine Verwendung proc Typ Regeln für Anbieter Domains hinzufügen. Dies ermöglicht es, die Plattform - Updates zukünftigen Kernel - Schnittstellen durch ausgesetzt aufzunehmen procfs und explizit beschriften nach Bedarf.

Debugfs (/sys/kernel/debug)

Debugfs in beiden beschriftbar file_contexts und genfscon . In Android 7.0 bis Android 10, beide plattform- und hersteller Label debugfs .

In Android 11, debugfs kann nicht auf die Produktion Geräte zugegriffen oder montiert werden. Die Gerätehersteller sollten entfernen debugfs .

Tracefs (/sys/kernel/debug/tracing)

Tracefs in beiden beschriftbar file_contexts und genfscon . In Android 7.0 nur die Plattform - Etiketten tracefs .

Empfehlung: Nur Plattform kann beschriften tracefs .

Sysfs (/sys)

Dateien in /sys werden mit beiden markierten file_contexts und genfscon . In Android 7.0, beide plattform- und hersteller Verwendung file_contexts und genfscon zu Label - Dateien in sysfs .

Empfehlung: Die Plattform kann beschriften sysfs Knoten , die nicht gerätespezifisch sind. Andernfalls darf nur der Anbieter Dateien kennzeichnen.

tmpfs (/dev)

Dateien in /dev können markiert werden file_contexts . In Android 7.0 finden Sie hier sowohl Plattform- als auch Anbieterlabeldateien.

Empfehlung: Der Anbieter beschriften kann nur Dateien in /dev/vendor (zB /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootfs (/)

Dateien in / können markiert werden file_contexts . In Android 7.0 finden Sie hier sowohl Plattform- als auch Anbieterlabeldateien.

Empfehlung: Nur System kann Dateien in beschriften / .

Daten (/Daten)

Die Daten werden durch eine Kombination von markiertem file_contexts und seapp_contexts .

Empfehlung: Disallow Anbieter Kennzeichnung außerhalb /data/vendor . Nur Plattform können andere Teile beschriften /data .

Kompatibilitätsattribute

Die SELinux-Richtlinie ist eine Interaktion zwischen Quell- und Zieltypen für bestimmte Objektklassen und Berechtigungen. Jedes Objekt (Prozesse, Dateien usw.), das von der SELinux-Richtlinie betroffen ist, kann nur einen Typ haben, aber dieser Typ kann mehrere Attribute haben.

Richtlinien werden hauptsächlich in Bezug auf vorhandene Typen geschrieben:

allow source_type target_type:target_class permission(s);

Dies funktioniert, weil die Richtlinie mit Kenntnissen aller Art geschrieben wurde. Wenn jedoch die Anbieterrichtlinie und die Plattformrichtlinie bestimmte Typen verwenden und sich die Bezeichnung eines bestimmten Objekts nur in einer dieser Richtlinien ändert, kann die andere Richtlinie enthalten, auf die zuvor vertrauter Zugriff erlangt oder verloren wurde. Zum Beispiel:

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

Könnte geändert werden in:

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

Obwohl die Verkäufer Politik gleich bleiben würde, die v_domain würde den Zugang verlieren aufgrund des fehlenden Politik für den neuen sysfs_A Typen.

Indem wir eine Richtlinie in Form von Attributen definieren, können wir dem zugrunde liegenden Objekt einen Typ geben, der ein Attribut hat, das der Richtlinie sowohl für den Plattform- als auch für den Anbietercode entspricht. Dies kann für alle Arten getan werden , um effektiv eine Attribut-Richtlinie zu erstellen , wobei konkrete Typen werden nie benutzt. In der Praxis wird dies nur erforderlich , für die Abschnitte der Politik , die zwischen der Plattform und herstellerüberlappen, die definiert sind und als Plattform öffentliche Ordnung vorgesehen , die als Teil der Lieferantenpolitik aufgebaut werden.

Das Definieren öffentlicher Richtlinien als versionierte Attribute erfüllt zwei Richtlinienkompatibilitätsziele:

  • Stellen Sie sicher , Lieferantencode weiter nach Plattform - Update an die Arbeit. Erreicht durch Hinzufügen von Attributen zu konkreten Typen von Objekten, die denen entsprechen, auf denen der Code des Anbieters beruht, wodurch der Zugriff erhalten bleibt.
  • Die Fähigkeit, deprecate Politik. Erreicht durch klare Abgrenzung von Richtliniensätzen in Attribute, die entfernt werden können, sobald die Version, der sie entsprechen, nicht mehr unterstützt wird. Die Entwicklung kann auf der Plattform fortgesetzt werden, da die alte Richtlinie noch in der Anbieterrichtlinie vorhanden ist und automatisch entfernt wird, wenn sie aktualisiert wird.

Beschreibbarkeit der Richtlinie

Um das Ziel zu erreichen, für die Richtlinienentwicklung keine Kenntnisse über bestimmte Versionsänderungen zu benötigen, enthält Android 8.0 eine Zuordnung zwischen plattform-öffentlichen Richtlinientypen und ihren Attributen. Typ foo wird auf Attribut zugeordnet foo_v N , wobei N die Version ausgerichtet. vN entspricht die PLATFORM_SEPOLICY_VERSION build variabel und ist von der Form MM.NN , in dem MM zu der Plattform SDK - Nummer entspricht und NN ist eine Plattform sepolicy spezifische Version.

Attribute in der öffentlichen Richtlinie sind nicht versioniert, sondern existieren als API, auf der Plattform- und Anbieterrichtlinien aufbauen können, um die Schnittstelle zwischen den beiden Partitionen stabil zu halten. Sowohl Plattform- als auch Anbieterrichtlinienautoren können Richtlinien weiterhin so schreiben, wie sie heute geschrieben sind.

Platform-öffentliche Ordnung exportiert als allow source_foo target_bar: class perm ; ist Teil der Anbieterrichtlinie. Während Kompilierung (die die entsprechende Version enthält) wird er in die Politik umgewandelt, die an den Lieferanten Teil der Vorrichtung gehen wird (gezeigt in der transformierten Common Intermediate Language (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

Da die Anbieterrichtlinie der Plattform nie voraus ist, sollte sie sich nicht auf frühere Versionen beziehen. Die Plattformrichtlinie muss jedoch wissen, wie weit die Anbieterrichtlinie zurückliegt, Attribute in ihre Typen aufnehmen und die Richtlinie entsprechend den versionierten Attributen festlegen.

Richtlinienunterschiede

Durch Hinzufügen automatisch Attribute Erstellen _v N an das Ende jeder Art tut nichts ohne Zuordnung von Attributen zu Typen über Version diffs. Android verwaltet eine Zuordnung zwischen Versionen für Attribute und eine Zuordnung von Typen zu diesen Attributen. Dies geschieht in den oben genannten Mapping-Dateien mit Anweisungen wie (CIL):

(typeattributeset foo_vN (foo))

Plattform-Upgrades

Im folgenden Abschnitt werden Szenarien für Plattform-Upgrades beschrieben.

Gleiche Typen

Dieses Szenario tritt auf, wenn ein Objekt die Bezeichnungen in Richtlinienversionen nicht ändert. Dies ist das gleiche für Quell- und Zieltypen und kann mit gesehen werden /dev/binder , der markiert ist binder_device in allen Versionen. Es wird in der transformierten Politik dargestellt als:

binder_device_v1 … binder_device_vN

Wenn ein Upgrade von v1v2 muss die Plattform Politik enthalten:

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

In der v1-Zuordnungsdatei (CIL):

(typeattributeset binder_device_v1 (binder_device))

In der v2-Zuordnungsdatei (CIL):

(typeattributeset binder_device_v2 (binder_device))

In der v1-Anbieterrichtlinie (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

In der v2-Anbieterrichtlinie (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Neue Typen

Dieses Szenario tritt auf, wenn die Plattform einen neuen Typ hinzugefügt hat, was beim Hinzufügen neuer Funktionen oder während der Richtlinienhärtung passieren kann.

  • Neue Funktion. Wenn der Typ ein Objekt kennzeichnet, das zuvor nicht vorhanden war (z. B. ein neuer Serviceprozess), hat der Anbietercode zuvor nicht direkt damit interagiert, sodass keine entsprechende Richtlinie vorhanden ist. Das dem Typ entsprechende neue Attribut hat kein Attribut in der vorherigen Version und benötigt daher keinen Eintrag in der Zuordnungsdatei, die auf diese Version abzielt.
  • Politik Härten. Wenn der Typ Politik Härtung darstellt, muss das neue Typ - Attribut auf eine Kette von Attributen entsprechend den vorherigen Link zurück (zum vorigen Beispiel ähnlich ändern /sys/A von sysfs bis sysfs_A ). Vendor Code stützt sich auf eine Regel , die den Zugang zu sysfs und umfassen muss diese Regel als Attribut des neuen Typs.

Wenn ein Upgrade von v1v2 muss die Plattform Politik enthalten:

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

In der v1-Zuordnungsdatei (CIL):

(typeattributeset sysfs_v1 (sysfs sysfs_A))

In der v2-Zuordnungsdatei (CIL):

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

In der v1-Anbieterrichtlinie (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

In der v2-Anbieterrichtlinie (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Entfernte Typen

Dieses (seltene) Szenario tritt auf, wenn ein Typ entfernt wird, was passieren kann, wenn das zugrunde liegende Objekt:

  • Bleibt, bekommt aber ein anderes Label.
  • Wird von der Plattform entfernt.

Während der Richtlinienlockerung wird ein Typ entfernt und das mit diesem Typ gekennzeichnete Objekt erhält ein anderes, bereits vorhandenes Label. Dabei handelt es sich um eine Verschmelzung von Attributzuordnungen: Der Vendor-Code muss weiterhin mit seinem bisherigen Attribut auf das zugrunde liegende Objekt zugreifen können, aber der Rest des Systems muss nun mit seinem neuen Attribut darauf zugreifen können.

Wenn das Attribut, auf das es umgestellt wurde, neu ist, erfolgt die Umetikettierung wie im Fall des neuen Typs, außer dass bei Verwendung eines vorhandenen Labels das Hinzufügen des alten Attributs new type dazu führen würde, dass andere Objekte ebenfalls mit diesem Typ gekennzeichnet werden neu erreichbar sein. Dies wird im Wesentlichen von der Plattform durchgeführt und wird als akzeptabler Kompromiss angesehen, um die Kompatibilität aufrechtzuerhalten.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Beispielversion 1: Kollabierende Typen (sysfs_A entfernen)

Wenn ein Upgrade von v1v2 muss die Plattform Politik enthalten:

type sysfs; (type sysfs) (in CIL)

In der v1-Zuordnungsdatei (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))

In der v2-Zuordnungsdatei (CIL):

(typeattributeset sysfs_v2 (sysfs))

In der v1-Anbieterrichtlinie (CIL):

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

In der v2-Anbieterrichtlinie (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Beispiel Version 2: Vollständig entfernen (Foo-Typ)

Wenn ein Upgrade von v1v2 muss die Plattform Politik enthalten:

# nothing - we got rid of the type

In der v1-Zuordnungsdatei (CIL):

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

In der v2-Zuordnungsdatei (CIL):

# nothing - get rid of it

In der v1-Anbieterrichtlinie (CIL):

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

In der v2-Anbieterrichtlinie (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Neue Klasse/Berechtigungen

Dieses Szenario tritt auf, wenn ein Plattform-Upgrade neue Richtlinienkomponenten einführt, die in früheren Versionen nicht vorhanden sind. Wenn zum Beispiel Android hinzugefügt , um die servicemanager Objekt - Manager, der das Add erstellt, finden und Listenberechtigungen, Vendor - Daemons wollen mit den registrieren servicemanager benötigt Berechtigungen , die nicht verfügbar waren. In Android 8.0 kann nur die Plattformrichtlinie neue Klassen und Berechtigungen hinzufügen.

Damit alle Domänen, die durch eine Anbieterrichtlinie erstellt oder erweitert werden könnten, die neue Klasse ungehindert verwenden können, muss die Plattformrichtlinie eine ähnliche Regel enthalten wie:

allow {domain -coredomain} *:new_class perm;

Dies kann sogar eine Richtlinie erfordern, die den Zugriff für alle Schnittstellentypen (öffentliche Richtlinien) ermöglicht, um sicherzustellen, dass das Anbieterimage Zugriff erhält. Wenn dies zu inakzeptablen Sicherheitsrichtlinien führt (wie dies bei den Servicemanager-Änderungen der Fall sein kann), könnte möglicherweise ein Hersteller-Upgrade erzwungen werden.

Klasse/Berechtigungen entfernt

Dieses Szenario tritt auf, wenn ein Objektmanager (wie die entfernt wird ZygoteConnection Objektmanager) und sollte nicht zu Problemen. Die Objektmanagerklasse und die Berechtigungen könnten in der Richtlinie definiert bleiben, bis die Herstellerversion sie nicht mehr verwendet. Dies geschieht durch Hinzufügen der Definitionen zur entsprechenden Mapping-Datei.

Anbieteranpassung für neue/umbenannte Typen

Neue Anbietertypen stehen im Mittelpunkt der Entwicklung von Anbieterrichtlinien, da sie benötigt werden, um neue Prozesse, Binärdateien, Geräte, Subsysteme und gespeicherte Daten zu beschreiben. Daher ist es zwingend erforderlich, die Erstellung von herstellerdefinierten Typen zuzulassen.

Da die Anbieterrichtlinie immer die älteste auf dem Gerät ist, müssen nicht alle Anbietertypen automatisch in Attribute in der Richtlinie konvertiert werden. Die Plattform verlässt sich auf nichts, was in der Anbieterrichtlinie angegeben ist, da die Plattform keine Kenntnis davon hat; jedoch liefert die Plattform die Attribute und öffentliche Typen es mit Objekten mit diesen Typen (wie beschriftet zu interagieren verwendet domain , sysfs_type , etc.). Für die Plattform mit diesen Objekten zu interagieren korrekt fortzusetzen, werden die Attribute und Typen müssen in geeigneter Weise angewendet und spezifische Regeln müssen auf die anpassbare Domänen (wie hinzugefügt werden init ).

Attributänderungen für Android 9

Geräte, die auf Android 9 aktualisiert werden, können die folgenden Attribute verwenden, Geräte, die mit Android 9 gestartet werden, jedoch nicht.

Übertreterattribute

Android 9 enthält diese domainbezogenen Attribute:

  • data_between_core_and_vendor_violators . Attribut für alle Domänen, die die Anforderung von Dateien nicht durch einen Pfad zwischen teilen verletzen vendor und coredomains . Plattform- und Anbieterprozesse sollten keine Dateien auf der Festplatte zur Kommunikation verwenden (instabiles ABI). Empfehlung:
    • Vendor Code sollte verwenden /data/vendor .
    • System verwenden sollte nicht /data/vendor .
  • system_executes_vendor_violators . Attribut für alle Systemdomänen (außer init und shell domains - shell domains ) , welche die Anforderung der nicht Ausführen hersteller Binärdateien verletzen. Die Ausführung von Anbieter-Binärdateien hat eine instabile API. Die Plattform sollte die Binärdateien des Anbieters nicht direkt ausführen. Empfehlung:
    • Solche Plattformabhängigkeiten von Anbieter-Binärdateien müssen sich hinter HIDL-HALs befinden.

      ODER

    • coredomains dass Notwendigkeit , den Zugang zu Anbieter - Binärdateien sollten an den Anbieter Partition und somit bewegt werden, aufhören, coredomain .

Nicht vertrauenswürdige Attribute

Nicht vertrauenswürdige Apps, die beliebigen Code hosten, sollten keinen Zugriff auf HwBinder-Dienste haben, mit Ausnahme derjenigen, die für den Zugriff von solchen Apps als ausreichend sicher gelten (siehe sichere Dienste unten). Die zwei Hauptgründe dafür sind:

  1. HwBinder-Server führen keine Clientauthentifizierung durch, da HIDL derzeit keine Anrufer-UID-Informationen verfügbar macht. Selbst wenn HIDL solche Daten offengelegt hat, arbeiten viele HwBinder-Dienste entweder auf einer Ebene unterhalb der von Apps (z. B. HALs) oder müssen sich für die Autorisierung nicht auf die App-Identität verlassen. Um sicher zu gehen, wird daher standardmäßig angenommen, dass jeder HwBinder-Dienst alle seine Clients als gleichberechtigt behandelt, um die von dem Dienst angebotenen Operationen auszuführen.
  2. HAL - Server (eine Untergruppe von HwBinder Dienstleistungen) enthält Code mit höherer Inzidenz von Sicherheitsfragen als system/core und hat Zugang zu den unteren Schichten des Stapels ( die ganzen Weg hinunter zu Hardware) damit Möglichkeiten zur Umgehung des Android - Sicherheitsmodelles zu erhöhen .

Sichere Dienste

Zu den sicheren Dienstleistungen gehören:

  • same_process_hwservice . Diese Dienste laufen (per Definition) im Prozess des Clients und haben somit den gleichen Zugriff wie die Clientdomäne, in der der Prozess läuft.
  • coredomain_hwservice . Diese Dienste stellen keine Risiken im Zusammenhang mit Grund Nr. 2 dar.
  • hal_configstore_ISurfaceFlingerConfigs . Dieser Dienst ist speziell für die Nutzung durch jede Domain konzipiert.
  • hal_graphics_allocator_hwservice . Diese Operationen werden auch angeboten surfaceflinger Binder - Service, die Anwendungen zugreifen dürfen.
  • hal_omx_hwservice . Dies ist eine HwBinder Version des mediacodec Binder - Service, die Anwendungen zugreifen dürfen.
  • hal_codec2_hwservice . Dies ist eine neuere Version von hal_omx_hwservice .

Nutzbare Attribute

Alle hwservices nicht als sicher angesehen haben das Attribut untrusted_app_visible_hwservice . Der entsprechende HAL - Server hat das Attribut untrusted_app_visible_halserver . Abzugsvorrichtung mit Android 9 darf nicht verwenden entweder untrusted Attribut.

Empfehlung:

  • Nicht vertrauenswürdige Apps sollten stattdessen mit einem Systemdienst kommunizieren, der mit dem Anbieter HIDL HAL kommuniziert. Zum Beispiel können Apps sprechen binderservicedomain , dann mediaserver (die eine ist binderservicedomain ) wiederum spricht mit dem hal_graphics_allocator .

    ODER

  • Apps, die einen direkten Zugang zu müssen vendor HALs sollten ihre eigenen herstellerdefinierten sepolicy Domain haben.

Dateiattributtests

Android 9 enthält Tests Aufbauzeit , die alle Dateien an bestimmten Orten haben die entsprechenden Attribute (wie alle Dateien in gewährleisten sysfs die erforderliche sysfs_type Attribut).

Plattform-öffentliche Richtlinien

Die Plattform-öffentliche Richtlinie ist der Kern der Konformität mit dem Android 8.0-Architekturmodell, ohne einfach die Vereinigung der Plattformrichtlinien von v1 und v2 beizubehalten. Anbieter sind auf eine Teilmenge von Plattformpolitik ausgesetzt , die nutzbare Typen und Attribute und Regeln auf diesen Typen und Attribute enthält , die dann einen Teil der Lieferantenpolitik (dh wird vendor_sepolicy.cil ).

Typen und Regeln automatisch im Kreditorengenerierten Politik in übersetzt werden attribute_v N , so dass alles Plattform-Typen zur Verfügung gestellt Attribute versioniert werden (jedoch Attribute werden nicht aufgezeichnet ). Die Plattform ist dafür verantwortlich, die von ihr bereitgestellten konkreten Typen den entsprechenden Attributen zuzuordnen, um sicherzustellen, dass die Anbieterrichtlinie weiterhin funktioniert und die für eine bestimmte Version bereitgestellten Regeln enthalten sind. Die Kombination aus Plattform-öffentlicher Richtlinie und Anbieterrichtlinie erfüllt das Ziel des Android 8.0-Architekturmodells, unabhängige Plattform- und Anbieter-Builds zu ermöglichen.

Zuordnung zu Attributketten

Wenn Attribute verwendet werden, um Richtlinienversionen zuzuordnen, wird ein Typ einem Attribut oder mehreren Attributen zugeordnet, wodurch sichergestellt wird, dass mit dem Typ gekennzeichnete Objekte über Attribute zugänglich sind, die ihren vorherigen Typen entsprechen.

Das Ziel aufrechtzuerhalten, Versionsinformationen vor dem Richtlinienschreiber zu verbergen, bedeutet, die versionierten Attribute automatisch zu generieren und sie den entsprechenden Typen zuzuweisen. Im allgemeinen Fall von statischen Typen ist dies einfach: type_foo zu Karten type_foo_v1 .

Für ein Objekt Etikettenwechsel wie sysfssysfs_A oder mediaserveraudioserver , diese Zuordnung zu schaffen ist nicht trivial (und ist in den oben beschriebenen Beispielen). Verwalter von Plattformrichtlinien müssen festlegen, wie die Zuordnung an Übergangspunkten für Objekte erstellt wird. Dazu müssen die Beziehung zwischen Objekten und ihren zugewiesenen Labels verstanden und der Zeitpunkt bestimmt werden. Aus Gründen der Abwärtskompatibilität muss diese Komplexität auf der Plattformseite verwaltet werden, die die einzige Partition ist, die uprev werden kann.

Versions-Uprevs

Der Einfachheit halber veröffentlicht die Android-Plattform eine Sepolicy-Version, wenn ein neuer Release-Zweig geschnitten wird. Wie oben beschrieben, wird die Versionsnummer in enthaltenen PLATFORM_SEPOLICY_VERSION und ist von der Form MM.nn , wobei MM entspricht den Wert SDK und nn ein privater Wert gehalten ist /platform/system/sepolicy. Zum Beispiel 19.0 für Kitkat, 21.0 für Lutscher, 22.0 für Lollipop-MR1 23.0 für Eibisch, 24.0 für Nougat, 25.0 für Nougat-MR1, 26.0 für Oreo, 27.0 für Oreo-MR1 und 28.0 für Android 9. Uprevs sind nicht immer ganze Zahlen. Zum Beispiel, wenn ein MR - Bump auf eine Version in eine inkompatible Änderung erfordert system/sepolicy/public aber nicht eine API Beule, dann , dass sepolicy Version könnte sein: vN.1 . Die Version , die in einem Entwicklungszweig ist ein nie zu-verwendet-in-Versand-Geräte 10000.0 .

Android kann beim Upreving die älteste Version verwerfen. Für Eingaben darüber, wann eine Version eingestellt werden soll, erfasst Android möglicherweise die Anzahl der Geräte mit Anbieterrichtlinien, auf denen diese Android-Version ausgeführt wird und die immer noch wichtige Plattform-Updates erhalten. Wenn die Anzahl unter einem bestimmten Schwellenwert liegt, wird diese Version als veraltet markiert.

Auswirkungen mehrerer Attribute auf die Leistung

Wie in beschrieben https://github.com/SELinuxProject/cil/issues/9 , eine große Anzahl von Attributen zu einem Typ Ergebnis in Performance - Probleme im Falle einer Politik Cache - Miss zugeordnet.

Dies wurde bestätigt , in Android ein Problem zu sein, so Änderungen vorgenommen wurden , um Android 8.0 Attribute der Politik durch die Politik Compiler sowie zu entfernen , nicht verwendete Attribute hinzugefügt zu entfernen. Durch diese Änderungen wurden Leistungsrückgänge behoben.

Kennzeichnung von SELinux-Kontexten

Um die Unterscheidung zwischen Plattform- und Anbieter-Sepolicy zu unterstützen, erstellt das System SELinux-Kontextdateien unterschiedlich, um sie getrennt zu halten.

Dateikontexte

Android 8.0 wurden folgende Änderungen eingeführt für file_contexts :

  • Zur Vermeidung von Überkopf zusätzliche Kompilierung auf dem Gerät während des Bootens, file_contexts aufhört in der binären Form zu existieren. Stattdessen sind sie lesbar, reguläre Ausdruck Textdatei wie {property, service}_contexts (wie sie vor 7.0).
  • Die file_contexts zwischen zwei Dateien aufgeteilt:
    • plat_file_contexts
      • Android - Plattform file_context , die keine gerätespezifische Etiketten, mit Ausnahme der Kennzeichnung Teile hat /vendor Partition , die genau richtige Funktionieren der sepolicy Dateien , um sicherzustellen , beschriftbar sind.
      • Muss in residieren system auf Partition /system/etc/selinux/plat_file_contexts auf Gerät und geladen wird init zusammen mit dem Verkäufer zu Beginn file_context .
    • vendor_file_contexts
      • Gerätespezifische file_context durch die Kombination gebaut file_contexts gefunden in die Verzeichnisse zu spitz durch BOARD_SEPOLICY_DIRS in der das Gerät Boardconfig.mk Dateien.
      • Muss installiert werden /vendor/etc/selinux/vendor_file_contexts in vendor - Partition und geladen werden init zusammen mit der Plattform zu Beginn file_context .

Immobilienkontexte

In Android 8.0, die property_contexts ist aufgeteilt zwischen zwei Dateien:

  • plat_property_contexts
    • Android - Plattform property_context , die keine gerätespezifische Etiketten hat.
    • Muss in residieren system auf Partition /system/etc/selinux/plat_property_contexts und geladen wird init zusammen mit dem Anbieter zu Beginn property_contexts .
  • vendor_property_contexts
    • Gerätespezifische property_context durch die Kombination gebaut property_contexts gefunden in die Verzeichnisse zu spitz durch BOARD_SEPOLICY_DIRS in Geräte Boardconfig.mk Dateien.
    • Muss in residieren vendor Partition /vendor/etc/selinux/vendor_property_contexts und geladen werden init zusammen mit der Plattform zu Beginn property_context

Servicekontexte

In Android 8.0, die service_contexts ist gespalten zwischen den folgenden Dateien:

  • plat_service_contexts
    • Android plattformspezifische service_context für den servicemanager . Die service_context hat keine gerätespezifische Etiketten.
    • Muss in residieren system auf Partition /system/etc/selinux/plat_service_contexts und geladen werden servicemanager zusammen mit dem Anbieter zu Beginn service_contexts .
  • vendor_service_contexts
    • Gerätespezifische service_context durch die Kombination gebaut service_contexts gefunden in die Verzeichnisse zu spitz durch BOARD_SEPOLICY_DIRS in der das Gerät Boardconfig.mk Dateien.
    • Muss in residieren vendor bei Partition /vendor/etc/selinux/vendor_service_contexts und geladen werden servicemanager zusammen mit der Plattform am Anfang service_contexts .
    • Obwohl servicemanager sieht für diese Datei beim Booten, für ein voll kompatible TREBLE Gerät, die vendor_service_contexts darf nicht vorhanden sein. Dies liegt daran , dass alle Interaktion zwischen vendor und system durchlaufen muss hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Android - Plattform hwservice_context für hwservicemanager , die keine gerätespezifische Etiketten hat.
    • Muss in residieren system auf Partition /system/etc/selinux/plat_hwservice_contexts und geladen wird hwservicemanager zusammen mit dem zu Beginn vendor_hwservice_contexts .
  • vendor_hwservice_contexts
    • Gerätespezifische hwservice_context durch die Kombination gebaut hwservice_contexts gefunden in die Verzeichnisse zu spitz durch BOARD_SEPOLICY_DIRS in der das Gerät Boardconfig.mk Dateien.
    • Muss in residieren vendor bei Partition /vendor/etc/selinux/vendor_hwservice_contexts und geladen wird hwservicemanager zusammen mit dem zu Beginn plat_service_contexts .
  • vndservice_contexts
    • Gerätespezifische service_context für die vndservicemanager durch die Kombination gebaut vndservice_contexts gefunden in die Verzeichnisse zu spitz durch BOARD_SEPOLICY_DIRS im Geräte Boardconfig.mk .
    • Diese Datei muss in residieren vendor auf Partition /vendor/etc/selinux/vndservice_contexts und geladen werden vndservicemanager am Start.

Seapp-Kontexte

In Android 8.0, die seapp_contexts ist aufgeteilt zwischen zwei Dateien:

  • plat_seapp_contexts
    • Android - Plattform seapp_context , die keine gerätespezifische Änderungen hat.
    • Muss in residieren system auf Partition /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Gerätespezifische Erweiterung Plattform seapp_context durch die Kombination gebaut seapp_contexts gefunden in den Verzeichnissen, auf die BOARD_SEPOLICY_DIRS in der das Gerät Boardconfig.mk Dateien.
    • Muss in residieren vendor bei Partition /vendor/etc/selinux/vendor_seapp_contexts .

MAC-Berechtigungen

In Android 8.0, die mac_permissions.xml ist aufgeteilt zwischen zwei Dateien:

  • Plattform mac_permissions.xml
    • Android - Plattform mac_permissions.xml , die keine gerätespezifische Änderungen hat.
    • Muss in residieren system auf Partition /system/etc/selinux/.
  • Non-Plattform mac_permissions.xml
    • Gerätespezifische Erweiterung Plattform mac_permissions.xml von gebaut mac_permissions.xml gefunden in den Verzeichnissen, auf die BOARD_SEPOLICY_DIRS in der das Gerät Boardconfig.mk Dateien.
    • Muss in residieren vendor bei Partition /vendor/etc/selinux/.