Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Richtlinienkompatibilität

In diesem Artikel wird beschrieben, wie Android die Richtlinienkompatibilitätsprobleme mit Plattform-OTAs behandelt, bei denen die neuen SELinux-Einstellungen der Plattform von den SELinux-Einstellungen der alten Anbieter abweichen können.

Das dreifache SELinux-Richtliniendesign berücksichtigt eine binäre Unterscheidung zwischen Plattform- und Anbieterrichtlinie . Das Schema wird komplizierter, wenn Herstellerpartitionen Abhängigkeiten generieren, z. B. 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 garantiert für eine Plattformversion verfügbar sind. Diese Richtlinie wird Anbietern von Anbieterrichtlinien zur Verfügung gestellt, damit Anbieter eine Anbieterrichtliniendatei erstellen können. In Kombination mit der von der Plattform bereitgestellten Richtlinie wird eine voll funktionsfähige Richtlinie für ein Gerät erstellt.

  • Für die Versionierung wird die exportierte plattformöffentliche Richtlinie als Attribut geschrieben .
  • Um das Schreiben von Richtlinien zu vereinfachen, werden exportierte Typen im Rahmen des Richtlinienerstellungsprozesses in versionierte Attribute umgewandelt. Öffentliche Typen können auch direkt bei Kennzeichnungsentscheidungen verwendet werden, die von Anbieterkontextdateien bereitgestellt werden.

Android verwaltet eine Zuordnung zwischen exportierten konkreten Typen in der Plattformrichtlinie und den entsprechenden versionierten Attributen für jede Plattformversion . Dadurch wird sichergestellt, dass Objekte, die mit einem Typ gekennzeichnet sind, das durch die plattformöffentliche Richtlinie in einer früheren Version garantierte Verhalten nicht beeinträchtigen. Diese Zuordnung wird beibehalten, indem für jede Plattformversion eine Zuordnungsdatei auf dem neuesten Stand gehalten wird, in der Informationen zur Attributmitgliedschaft für jeden in öffentliche Richtlinien exportierten Typ gespeichert werden.

Objektbesitz und Kennzeichnung

Beim Anpassen von Richtlinien in Android 8.0 und höher muss der Besitz für jedes Objekt klar definiert sein, damit Plattform- und Anbieterrichtlinien getrennt bleiben. Wenn beispielsweise der Anbieter /dev/foo und die Plattform in einem nachfolgenden OTA /dev/foo beschriftet, liegt ein undefiniertes Verhalten vor. Für SELinux manifestiert sich dies als Markierungskollision. Der Geräteknoten kann nur eine einzige Bezeichnung haben, die in die zuletzt angewendete Bezeichnung aufgelöst wird. Als Ergebnis:

  • Prozesse, die Zugriff auf das nicht erfolgreich angewendete Etikett benötigen , verlieren den Zugriff auf die Ressource.
  • Prozesse, die Zugriff auf die Datei erhalten, können unterbrochen werden, weil der falsche Geräteknoten erstellt wurde.

Systemeigenschaften können auch Kollisionen benennen, die zu undefiniertem Verhalten auf dem System führen können (sowie zur SELinux-Kennzeichnung). Kollisionen zwischen Plattform- und Herstellerbezeichnungen können für jedes Objekt auftreten, das eine SELinux-Bezeichnung hat, einschließlich Eigenschaften, Dienste, Prozesse, Dateien und Sockets. Um diese Probleme zu vermeiden, definieren Sie das Eigentum an diesen Objekten klar.

Zusätzlich zu Etikettenkollisionen können auch SELinux-Typ- / Attributnamen kollidieren. Eine Kollision zwischen Typ und Attributname führt immer zu einem Fehler beim Richtlinien-Compiler.

Typ / Attribut-Namespace

SELinux erlaubt nicht mehrere Deklarationen desselben Typs / Attributs. Richtlinien mit doppelten Deklarationen können nicht kompiliert werden. Um Kollisionen von Typ- und Attributnamen zu vermeiden, sollten alle Herstellerdeklarationen mit np_ beginnend np_ .

type foo, domain; → type np_foo, domain;

Besitz von Systemeigenschaften und Prozesskennzeichnungen

Das Vermeiden von Beschriftungskollisionen lässt sich am besten mit Eigenschafts-Namespaces lösen. Stellen Sie sicher, dass alle Anbietereigenschaften ihre eigenen Präfixe haben, um Plattformeigenschaften leicht zu identifizieren und Namenskonflikte beim Umbenennen oder Hinzufügen von Eigenschaften für exportierte Plattformen zu vermeiden:

Art der Immobilie Akzeptable Präfixe
lesbar vendor.
schreibgeschützt ro.vendor.
ro.boot.
ro.hardware.
hartnäckig persist.vendor.

Anbieter können weiterhin ro.boot.* (Das vom Kernel cmdline stammt) und ro.hardware.* (Eine offensichtliche hardwarebezogene Eigenschaft) verwenden.

Alle Herstellerdienste in init rc-Dateien sollten einen vendor. für Dienste in init rc-Dateien von Nicht-Systempartitionen. Ähnliche Regeln gelten für die SELinux-Labels für die Herstellereigenschaften ( vendor_ für die Herstellereigenschaften).

Dateieigentum

Das Verhindern von Kollisionen für Dateien ist eine Herausforderung, da Plattform- und Herstellerrichtlinien normalerweise Beschriftungen für alle Dateisysteme bereitstellen. Im Gegensatz zur Typbenennung ist der Namespace von Dateien nicht praktikabel, da viele davon vom Kernel erstellt werden. Befolgen Sie die Benennungsrichtlinien für Dateisysteme in diesem Abschnitt, um diese Kollisionen zu vermeiden. Für Android 8.0 sind dies Empfehlungen ohne technische Durchsetzung. Diese Empfehlungen werden in Zukunft von der Vendor Test Suite (VTS) durchgesetzt.

System (/ System)

Nur das System-Image muss Beschriftungen für /system Komponenten über file_contexts , service_contexts usw. service_contexts . Wenn Beschriftungen für /system Komponenten in der /vendor Richtlinie hinzugefügt werden, ist möglicherweise keine OTA-Aktualisierung nur für Frameworks möglich.

Anbieter (/ Anbieter)

Die AOSP SELinux-Richtlinie kennzeichnet bereits Teile der vendor mit denen die Plattform interagiert, wodurch das Schreiben von SELinux-Regeln für Plattformprozesse ermöglicht wird, um Teile der vendor zu kommunizieren und / oder darauf zuzugreifen. Beispiele:

/vendor Von der Plattform bereitgestelltes Etikett Plattformprozesse je nach Label
/vendor(/. * )? vendor_file Alle HAL-Clients in Framework, 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.

Daher müssen beim Beschriften zusätzlicher Dateien in der vendor bestimmte Regeln befolgt (durch neverallows durchgesetzt) ​​werden:

  • vendor_file muss die Standardbezeichnung für alle Dateien in der vendor . 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.
  • Vermeiden Sie es, andere Dateien als exec_types in der vendor kennzeichnen, um Konflikte mit zukünftigen Plattform- / Framework-Updates zu vermeiden.
  • Alle Bibliotheksabhängigkeiten für AOSP-identifizierte Prozess-HALs müssen als same_process_hal_file.

Procfs (/ proc)

Dateien in /proc dürfen nur mit dem genfscon Label gekennzeichnet werden. In Android 7.0 verwendeten sowohl die Plattform- als auch die Herstellerrichtlinie genfscon , um Dateien in procfs genfscon .

Empfehlung: Nur Plattformrichtlinienbezeichnungen /proc . Wenn vendor Zugriff auf Dateien in /proc benötigen, die derzeit mit der Standardbezeichnung ( proc ) gekennzeichnet sind, sollten die Herstellerrichtlinien diese nicht explizit kennzeichnen und stattdessen den generischen proc Typ verwenden, um Regeln für Herstellerdomänen hinzuzufügen. Auf diese Weise können die Plattformaktualisierungen zukünftige Kernel-Schnittstellen aufnehmen, die über procfs verfügbar gemacht werden, und diese bei Bedarf explizit kennzeichnen.

Debugfs (/ sys / kernel / debug)

Debugfs können sowohl in file_contexts als auch in file_contexts genfscon . In Android 7.0 bis Android 10 debugfs sowohl Plattform- als auch Herstellerlabels.

In Android 11 kann nicht auf debugfs zugegriffen oder auf Produktionsgeräten gemountet werden. Gerätehersteller sollten debugfs entfernen.

Tracefs (/ sys / kernel / debug / tracing)

Tracefs können sowohl in file_contexts als auch in file_contexts genfscon . In Android 7.0 beschriftet nur die Plattform tracefs .

Empfehlung: Nur die Plattform darf tracefs .

Sysfs (/ sys)

Dateien in /sys können sowohl mit file_contexts als auch mit file_contexts genfscon . In Android 7.0 verwenden sowohl die Plattform als auch der Anbieter file_contexts und genfscon , um Dateien in sysfs genfscon .

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

tmpfs (/ dev)

Dateien in /dev können in file_contexts . In Android 7.0 werden hier sowohl Plattform- als auch Hersteller-Label-Dateien angezeigt.

Empfehlung: Der /dev/vendor darf nur Dateien in /dev/vendor (z. B. /dev/vendor/foo , /dev/vendor/socket/bar ) /dev/vendor/foo .

Rootfs (/)

Dateien in / können in file_contexts . In Android 7.0 werden hier sowohl Plattform- als auch Hersteller-Label-Dateien angezeigt.

Empfehlung: Nur das System darf Dateien in / kennzeichnen.

Daten (/ Daten)

Daten werden durch eine Kombination aus file_contexts und seapp_contexts .

Empfehlung: Lieferantenkennzeichnung außerhalb von /data/vendor zulassen. Nur die Plattform darf andere Teile von /data .

Kompatibilitätsattribute

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

Die 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 Herstellerrichtlinie und die Plattformrichtlinie bestimmte Typen verwenden und sich die Bezeichnung eines bestimmten Objekts nur in einer dieser Richtlinien ändert, kann die andere Richtlinie Richtlinien enthalten, auf die zuvor Zugriff zugegriffen oder verloren wurde. Beispielsweise:

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 zu:

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

Obwohl die Herstellerrichtlinie dieselbe bleiben würde, würde die v_domain den Zugriff verlieren, da für den neuen Typ sysfs_A keine Richtlinie sysfs_A .

Durch Definieren einer Richtlinie in Bezug auf Attribute können wir dem zugrunde liegenden Objekt einen Typ zuweisen, dessen Attribut der Richtlinie sowohl für den Plattform- als auch für den Lieferantencode entspricht. Dies kann für alle Typen durchgeführt werden, um effektiv eine Attributrichtlinie zu erstellen , in der konkrete Typen niemals verwendet werden. In der Praxis ist dies nur für die Teile der Richtlinie erforderlich, die sich zwischen Plattform und Anbieter überschneiden und als öffentliche Plattformrichtlinie definiert und bereitgestellt werden , die als Teil der Anbieterrichtlinie erstellt wird.

Das Definieren der öffentlichen Richtlinie als versionierte Attribute erfüllt zwei Richtlinienkompatibilitätsziele:

  • Stellen Sie sicher, dass der Herstellercode nach der Plattformaktualisierung weiterhin funktioniert . Dies wird erreicht, indem konkreten Typen Attribute für Objekte hinzugefügt werden, die denen entsprechen, auf die sich der Herstellercode stützt, wobei der Zugriff erhalten bleibt.
  • Fähigkeit, Richtlinien abzulehnen . Dies wird erreicht, indem Richtliniensätze klar in Attribute unterteilt werden, 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 bekannt ist, dass die alte Richtlinie noch in der Herstellerrichtlinie vorhanden ist und bei einem Upgrade automatisch entfernt wird.

Richtlinienbeschreibbarkeit

Um das Ziel zu erreichen, keine Kenntnisse über bestimmte Versionsänderungen für die Richtlinienentwicklung zu benötigen, enthält Android 8.0 eine Zuordnung zwischen plattformoffenen Richtlinientypen und ihren Attributen. Der Typ foo wird dem Attribut foo_v N , wobei N die foo_v N ist. vN entspricht der Build-Variablen PLATFORM_SEPOLICY_VERSION und hat die Form MM.NN , wobei MM der Plattform-SDK-Nummer entspricht und NN eine plattformsepolizitätsspezifische Version ist.

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

Plattform-öffentliche Richtlinie exportiert als allow source_foo target_bar: class perm ; ist Teil der Lieferantenrichtlinie. Während der Kompilierung (einschließlich der entsprechenden Version) wird sie in die Richtlinie umgewandelt, die an den Herstellerteil des Geräts gesendet wird (angezeigt in der transformierten Common Intermediate Language (CIL)):

 (allow source_foo_vN target_bar_vN (class (perm)))

Da die Herstellerrichtlinien der Plattform niemals voraus sind, sollten sie sich nicht mit früheren Versionen befassen. Die Plattformrichtlinie muss jedoch wissen, wie weit die Herstellerrichtlinie zurückliegt, Attribute zu ihren Typen hinzufügen und Richtlinien festlegen, die versionierten Attributen entsprechen.

Richtlinienunterschiede

Das automatische Erstellen von Attributen durch Hinzufügen von _v N am Ende jedes Typs führt zu nichts, ohne Attribute Attributen über Versionsunterschiede hinweg zuzuordnen. Android verwaltet eine Zuordnung zwischen Versionen für Attribute und eine Zuordnung von Typen zu diesen Attributen. Dies erfolgt in den oben genannten Zuordnungsdateien 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 in Richtlinienversionen keine Beschriftungen ändert. Dies gilt auch für Quell- und binder_device und kann mit /dev/binder binder_device in allen Releases mit binder_device gekennzeichnet ist. Es wird in der transformierten Politik dargestellt als:

binder_device_v1 … binder_device_vN

Beim Upgrade von v1v2 muss die Plattformrichtlinie Folgendes 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-Lieferantenrichtlinie (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

In der v2-Lieferantenrichtlinie (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Neue Typen

Dieses Szenario tritt auf, wenn die Plattform einen neuen Typ hinzugefügt hat. Dies kann beim Hinzufügen neuer Funktionen oder beim Härten von Richtlinien auftreten.

  • Neue Funktion . Wenn der Typ ein Objekt kennzeichnet, das zuvor nicht vorhanden war (z. B. ein neuer Serviceprozess), hat der Lieferantencode zuvor nicht direkt mit ihm interagiert, sodass keine entsprechende Richtlinie vorhanden ist. Das neue Attribut, das dem Typ entspricht, hat in der vorherigen Version kein Attribut und benötigt daher keinen Eintrag in der Zuordnungsdatei, die auf diese Version abzielt.
  • Policy Hardening . Wenn der Typ die Richtlinienhärtung darstellt, muss das neue sysfs_A mit einer Kette von Attributen verknüpft werden, die dem vorherigen entsprechen (ähnlich wie im vorherigen Beispiel, in dem /sys/A von sysfs in sysfs_A ). Der Herstellercode basiert auf einer Regel, die den Zugriff auf sysfs , und muss diese Regel als Attribut des neuen Typs einschließen.

Beim Upgrade von v1v2 muss die Plattformrichtlinie Folgendes 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-Lieferantenrichtlinie (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

In der v2-Lieferantenrichtlinie (CIL):

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

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

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

Beim Lösen von Richtlinien wird ein Typ entfernt und das mit diesem Typ gekennzeichnete Objekt erhält eine andere, bereits vorhandene Bezeichnung. Dies stellt eine Zusammenführung von Attributzuordnungen dar: Der Herstellercode muss weiterhin über das Attribut, das es früher besaß, auf das zugrunde liegende Objekt zugreifen können, aber der Rest des Systems muss jetzt mit seinem neuen Attribut darauf zugreifen können.

Wenn das Attribut, auf das es umgeschaltet wurde, neu ist, ist die Neukennzeichnung dieselbe wie im Fall des neuen Typs, außer dass bei Verwendung einer vorhandenen Beschriftung das Hinzufügen des neuen Attributs neuer Typ andere Objekte verursachen würde, die ebenfalls mit diesem Typ gekennzeichnet sind neu zugänglich sein. Dies wird im Wesentlichen von der Plattform durchgeführt und als akzeptabler Kompromiss zur Aufrechterhaltung der Kompatibilität angesehen.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Beispiel Version 1: Reduzieren von Typen (Entfernen von sysfs_A)

Beim Upgrade von v1v2 muss die Plattformrichtlinie Folgendes 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 Vendor Policy (CIL):

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

In der v2-Lieferantenrichtlinie (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Beispiel Version 2: Vollständiges Entfernen (Foo-Typ)

Beim Upgrade von v1v2 muss die Plattformrichtlinie Folgendes 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 Vendor Policy (CIL):

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

In der v2-Lieferantenrichtlinie (CIL):

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

Dieses Szenario tritt auf, wenn bei einem Plattform-Upgrade neue Richtlinienkomponenten eingeführt werden, die in früheren Versionen nicht vorhanden waren. Wenn Android beispielsweise den servicemanager Objektmanager hinzufügte, der die Berechtigungen zum Hinzufügen, Suchen und servicemanager benötigten Hersteller-Daemons, die sich beim servicemanager registrieren möchten, 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 von der Herstellerrichtlinie erstellt oder erweitert werden konnten, die neue Klasse ohne Behinderung verwenden können, muss die Plattformrichtlinie eine Regel enthalten, die der folgenden ähnelt:

allow {domain -coredomain} *:new_class perm;

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

Klasse / Berechtigungen entfernt

Dieses Szenario tritt auf, wenn ein Objektmanager entfernt wird (z. B. der ZygoteConnection Objektmanager) und sollte keine Probleme verursachen. Die Objektmanagerklasse und die Berechtigungen können in der Richtlinie definiert bleiben, bis die Herstellerversion sie nicht mehr verwendet. Dies erfolgt durch Hinzufügen der Definitionen zur entsprechenden Zuordnungsdatei.

Lieferantenanpassung für neue / neu gekennzeichnete Typen

Neue Anbietertypen bilden den Kern der Entwicklung von Anbieterrichtlinien, da sie zur Beschreibung neuer Prozesse, Binärdateien, Geräte, Subsysteme und gespeicherter Daten benötigt werden. Daher ist es unbedingt erforderlich, die Erstellung von vom Hersteller definierten Typen zuzulassen.

Da die Lieferantenrichtlinie immer die älteste auf dem Gerät ist, müssen nicht alle Lieferantentypen automatisch in Attribute in der Richtlinie konvertiert werden. Die Plattform stützt sich nicht auf irgendetwas, das in der Herstellerrichtlinie angegeben ist, da die Plattform keine Kenntnis davon hat. Die Plattform stellt jedoch die Attribute und öffentlichen Typen bereit, die sie für die Interaktion mit Objekten verwendet, die mit diesen Typen gekennzeichnet sind (z. B. domain , sysfs_type usw.). Damit die Plattform weiterhin korrekt mit diesen Objekten interagieren kann, müssen die Attribute und Typen entsprechend angewendet werden und den anpassbaren Domänen (z. B. init ) müssen möglicherweise bestimmte Regeln hinzugefügt werden.

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, dürfen dies jedoch nicht.

Verstoßattribute

Android 9 enthält die folgenden domänenbezogenen Attribute:

  • data_between_core_and_vendor_violators . Attribut für alle Domänen, die gegen die Anforderung verstoßen, Dateien nicht nach Pfad zwischen vendor und coredomains . Plattform- und Herstellerprozesse sollten keine On-Disk-Dateien für die Kommunikation verwenden (instabiles ABI). Empfehlung:
    • Der Herstellercode sollte /data/vendor .
    • Das System sollte /data/vendor nicht verwenden.
  • system_executes_vendor_violators . Attribut für alle Systemdomänen (außer init und shell domains ), die gegen die Anforderung verstoßen, keine Hersteller-Binärdateien auszuführen. Die Ausführung von Hersteller-Binärdateien hat eine instabile API. Die Plattform sollte Hersteller-Binärdateien nicht direkt ausführen. Empfehlung:
    • Solche Plattformabhängigkeiten von Hersteller-Binärdateien müssen hinter HIDL-HALs stehen.

      ODER

    • coredomains , die Zugriff auf Vendor-Binärdateien benötigen, sollten auf die Vendor-Partition verschoben werden und somit coredomain .

Nicht vertrauenswürdige Attribute

Nicht vertrauenswürdige Apps, die beliebigen Code hosten, sollten keinen Zugriff auf HwBinder-Dienste haben, außer solchen, die für den Zugriff über solche Apps als ausreichend sicher angesehen werden (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 bereitstellt. Selbst wenn HIDL solche Daten verfügbar gemacht hat, arbeiten viele HwBinder-Dienste entweder auf einer Ebene, die unter der von Apps (z. B. HALs) liegt, oder dürfen sich bei der Autorisierung nicht auf die App-Identität verlassen. Aus Sicherheitsgründen wird daher standardmäßig davon ausgegangen, dass jeder HwBinder-Dienst alle seine Clients als gleichermaßen berechtigt behandelt, die vom Dienst angebotenen Vorgänge auszuführen.
  2. HAL-Server (eine Teilmenge der HwBinder-Dienste) enthalten Code mit einer höheren Häufigkeit von Sicherheitsproblemen als system/core und haben Zugriff auf die unteren Schichten des Stapels (bis hin zur Hardware), wodurch sich die Möglichkeiten zur Umgehung des Android-Sicherheitsmodells erhöhen .

Sichere Dienste

Zu den sicheren Diensten gehören:

  • same_process_hwservice . Diese Dienste werden (per Definition) im Prozess des Clients ausgeführt und haben daher denselben Zugriff wie die Clientdomäne, in der der Prozess ausgeführt wird.
  • coredomain_hwservice . Diese Dienste bergen keine Risiken im Zusammenhang mit Grund Nr. 2.
  • hal_configstore_ISurfaceFlingerConfigs . Dieser Dienst wurde speziell für die Verwendung durch eine beliebige Domain entwickelt.
  • hal_graphics_allocator_hwservice . Diese Operationen werden auch vom surfaceflinger Binder-Service angeboten, auf den Apps zugreifen dürfen.
  • hal_omx_hwservice . Dies ist eine HwBinder-Version des mediacodec Binder-Dienstes, auf die Apps zugreifen dürfen.
  • hal_codec2_hwservice . Dies ist eine neuere Version von hal_omx_hwservice .

Verwendbare Attribute

Alle hwservices nicht als sicher eingestuft werden, haben das Attribut untrusted_app_visible_hwservice . Die entsprechenden HAL-Server haben das Attribut untrusted_app_visible_halserver . Geräte, die mit Android 9 gestartet werden, dürfen keines der untrusted Attribute verwenden.

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 direkten Zugriff auf vendor HALs benötigen, sollten über eine eigene vom Hersteller definierte sepolicy-Domäne verfügen.

Dateiattributtests

Android 9 enthält Build-Time-Tests , mit denen sichergestellt wird, dass alle Dateien an bestimmten Speicherorten über die entsprechenden Attribute verfügen (z. B. haben alle Dateien in sysfs das erforderliche Attribut sysfs_type ).

Plattform-öffentliche Politik

Die plattformöffentliche Richtlinie ist der Kern der Konformität mit dem Android 8.0-Architekturmodell, ohne lediglich die Vereinigung der Plattformrichtlinien aus Version 1 und Version 2 beizubehalten. Anbieter sind einer Teilmenge der Plattformrichtlinie ausgesetzt, die verwendbare Typen und Attribute sowie Regeln für diese Typen und Attribute enthält, die dann Teil der Anbieterrichtlinie werden (z. B. vendor_sepolicy.cil ).

Typen und Regeln werden in der vom Hersteller generierten Richtlinie automatisch in attribute_v N , sodass alle von der Plattform bereitgestellten Typen versionierte Attribute sind (Attribute werden jedoch nicht versioniert). Die Plattform ist dafür verantwortlich, die von ihr bereitgestellten konkreten Typen den entsprechenden Attributen zuzuordnen, um sicherzustellen, dass die Lieferantenrichtlinie weiterhin funktioniert und die für eine bestimmte Version bereitgestellten Regeln enthalten sind. Die Kombination aus Plattform-Public-Policy und Vendor-Policy erfüllt das Ziel des Architekturmodells für Android 8.0, unabhängige Plattform- und Vendor-Builds zu ermöglichen.

Zuordnung zu Attributketten

Wenn Sie Attribute verwenden, um Richtlinienversionen zuzuordnen, wird ein Typ einem Attribut oder mehreren Attributen zugeordnet, um sicherzustellen, dass Objekte, die mit dem Typ gekennzeichnet sind, über Attribute zugänglich sind, die ihren vorherigen Typen entsprechen.

Wenn Sie das Ziel beibehalten, Versionsinformationen vor dem Richtlinienschreiber zu verbergen, werden die versionierten Attribute automatisch generiert und den entsprechenden Typen zugewiesen. Im allgemeinen Fall von statischen Typen ist dies unkompliziert: type_foo wird 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). Plattformrichtlinienbetreuer müssen festlegen, wie die Zuordnung an Übergangspunkten für Objekte erstellt werden soll. Dazu muss die Beziehung zwischen Objekten und den ihnen zugewiesenen Beschriftungen verstanden und festgelegt werden, wann dies geschieht. Aus Gründen der Abwärtskompatibilität muss diese Komplexität auf der Plattformseite verwaltet werden. Dies ist die einzige Partition, die möglicherweise aktualisiert wird.

Version uprevs

Der Einfachheit halber veröffentlicht die Android-Plattform eine sepolicy-Version, wenn ein neuer Release-Zweig abgeschnitten wird. Wie oben beschrieben, ist die Versionsnummer in PLATFORM_SEPOLICY_VERSION und hat die Form MM.nn , wobei MM dem SDK-Wert entspricht und nn ein privater Wert ist, der in /platform/system/sepolicy. Zum Beispiel 19.0 für Kitkat, 21.0 für Lollipop, 22.0 für Lollipop-MR1 23.0 für Marshmallow, 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 nicht immer ganze Zahlen. Wenn beispielsweise ein MR-Bump für eine Version eine inkompatible Änderung von system/sepolicy/public jedoch kein API-Bump, kann diese sepolicy-Version wie vN.1 lauten: vN.1 . Die in einem Entwicklungszweig vorhandene Version ist eine 10000.0 niemals in Versandgeräten verwendet werden 10000.0 .

Android kann die älteste Version beim Hochfahren verwerfen. Für die Eingabe, wann eine Version veraltet werden soll, erfasst Android möglicherweise die Anzahl der Geräte mit Herstellerrichtlinien, auf denen diese Android-Version ausgeführt wird und die weiterhin wichtige Plattform-Updates erhalten. Wenn die Anzahl unter einem bestimmten Schwellenwert liegt, ist diese Version veraltet.

Auswirkungen mehrerer Attribute auf die Leistung

Wie unter https://github.com/SELinuxProject/cil/issues/9 beschrieben , führt eine große Anzahl von Attributen, die einem Typ zugewiesen sind, zu Leistungsproblemen im Falle eines Fehlschlags im Richtliniencache.

Es wurde bestätigt, dass dies ein Problem in Android ist. Daher wurden Änderungen an Android 8.0 vorgenommen, um Attribute zu entfernen, die vom Richtliniencompiler zur Richtlinie hinzugefügt wurden, sowie nicht verwendete Attribute zu entfernen. Diese Änderungen lösten Leistungsregressionen auf.

Kennzeichnung von SELinux-Kontexten

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

Dateikontexte

Android 8.0 hat die folgenden Änderungen für file_contexts :

  • Um zusätzlichen Kompilierungsaufwand auf dem Gerät während des Startvorgangs zu vermeiden, sind file_contexts nicht mehr in binärer Form vorhanden. Stattdessen handelt es sich um lesbare Textdateien mit regulären Ausdrücken wie {property, service}_contexts (wie vor 7.0).
  • Die file_contexts werden auf zwei Dateien aufgeteilt:
    • plat_file_contexts
      • Android-Plattform file_context ohne gerätespezifische Beschriftungen, mit Ausnahme der Beschriftung von Teilen der /vendor Partition, die genau beschriftet werden müssen, um das ordnungsgemäße Funktionieren der sepolicy-Dateien sicherzustellen.
      • 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
      • file_context der durch Kombinieren von file_contexts die in den Verzeichnissen enthalten sind, auf die BOARD_SEPOLICY_DIRS in den Boardconfig.mk Dateien des Geräts Boardconfig.mk .
      • Muss unter /vendor/etc/selinux/vendor_file_contexts in der vendor installiert und zu Beginn von init zusammen mit der Plattform file_context .

Eigenschaftskontexte

In Android 8.0 werden die property_contexts zwei Dateien aufgeteilt:

  • plat_property_contexts
    • Android-Plattform property_context ohne gerätespezifische Beschriftungen.
    • 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
    • BOARD_SEPOLICY_DIRS property_context der durch Kombinieren von property_contexts die in den Verzeichnissen gefunden werden, auf die BOARD_SEPOLICY_DIRS in den Boardconfig.mk Dateien des Geräts Boardconfig.mk .
    • Muss sich in der vendor unter /vendor/etc/selinux/vendor_property_contexts und zu Beginn von init zusammen mit der Plattform property_context geladen werden

Servicekontexte

In Android 8.0 werden die service_contexts die folgenden Dateien aufgeteilt:

  • plat_service_contexts
    • Android plattformspezifischer service_context für den servicemanager . Der service_context hat keine gerätespezifischen Bezeichnungen.
    • 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
    • service_context der durch Kombinieren von service_contexts in den Verzeichnissen erstellt wird, auf die BOARD_SEPOLICY_DIRS in den Boardconfig.mk Dateien des Geräts Boardconfig.mk .
    • Muss sich in der vendor unter /vendor/etc/selinux/vendor_service_contexts und zu Beginn vom servicemanager zusammen mit der Plattform service_contexts .
    • Obwohl der servicemanager beim Booten nach dieser Datei sucht, dürfen für ein vollständig kompatibles TREBLE Gerät die vendor_service_contexts NICHT vorhanden sein. Dies liegt daran, dass alle Interaktionen zwischen vendor und system über hwservicemanager / hwbinder hwservicemanager hwbinder .
  • plat_hwservice_contexts
    • Android-Plattform hwservice_context für hwservicemanager ohne gerätespezifische Bezeichnungen.
    • 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
    • hwservice_context der durch Kombinieren von hwservice_contexts in den Verzeichnissen erstellt wird, auf die BOARD_SEPOLICY_DIRS in den Boardconfig.mk Dateien des Geräts Boardconfig.mk .
    • Muss sich in der vendor unter /vendor/etc/selinux/vendor_hwservice_contexts und zu Beginn vom hwservicemanager zusammen mit den plat_service_contexts .
  • vndservice_contexts
    • service_context für den vndservicemanager der durch Kombinieren von vndservice_contexts die in den Verzeichnissen gefunden werden, auf die BOARD_SEPOLICY_DIRS in der BOARD_SEPOLICY_DIRS des Geräts Boardconfig.mk .
    • Diese Datei muss sich in der vendor unter /vendor/etc/selinux/vndservice_contexts und zu Beginn vom vndservicemanager geladen werden.

Seapp-Kontexte

In Android 8.0 wird der seapp_contexts zwei Dateien aufgeteilt:

  • plat_seapp_contexts
    • Android-Plattform seapp_context ohne gerätespezifische Änderungen.
    • Muss in residieren system auf Partition /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • seapp_context Erweiterung der Plattform seapp_context die durch Kombinieren von seapp_contexts in den Verzeichnissen erstellt wird, auf die BOARD_SEPOLICY_DIRS in den Boardconfig.mk Dateien des Geräts Boardconfig.mk .
    • Muss sich in der vendor unter /vendor/etc/selinux/vendor_seapp_contexts .

MAC-Berechtigungen

In Android 8.0 wird die mac_permissions.xml zwei Dateien aufgeteilt:

  • Plattform mac_permissions.xml
    • Android-Plattform mac_permissions.xml ohne gerätespezifische Änderungen.
    • Muss in residieren system auf Partition /system/etc/selinux/.
  • Nicht-Plattform mac_permissions.xml
    • mac_permissions.xml Erweiterung der Plattform mac_permissions.xml aus mac_permissions.xml in den Verzeichnissen, auf die BOARD_SEPOLICY_DIRS in den Boardconfig.mk Dateien des Geräts Boardconfig.mk .
    • Muss sich in der vendor unter /vendor/etc/selinux/.