Richtlinienkompatibilität

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

Treble-basiertes SELinux-Richtliniendesign berücksichtigt binäre Unterscheidung zwischen der Plattform- und der Anbieter-Richtlinie; wird das Schema komplexer, wenn Anbieterpartitionen Abhängigkeiten generieren, z. B. platform < vendor < oem

Ab Android 8.0 wird die globale SELinux-Richtlinie in private und öffentlichen Komponenten. Öffentliche Komponenten bestehen aus der Richtlinie und den zugehörigen die für eine Plattformversion garantiert verfügbar sind. Diese Richtlinie wird Erstellern von Anbieterrichtlinien angezeigt, damit sie Anbietern die Möglichkeit geben können, eine Anbieterrichtliniendatei, 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 Versionsverwaltung wird die exportierte Plattformrichtlinie so geschrieben: attributes.
• Um das Schreiben von Richtlinien zu erleichtern, werden exportierte Typen in versionierte Attribute im Rahmen des Richtlinienerstellungsprozesses verwenden. Öffentlich Typen können auch direkt bei Label-Entscheidungen des Anbieters verwendet werden. Kontextdateien.

Android verwaltet eine Zuordnung zwischen exportierten Betontypen in der Plattform. und die entsprechenden versionierten Attribute für jede Plattform . Dadurch wird sichergestellt, dass beim Kennzeichnen von Objekten mit einem Typ nicht gegen das Verhalten verstößt, das in einer früheren Version. Diese Zuordnung wird verwaltet, indem eine Zuordnungsdatei für <ph type="x-smartling-placeholder"></ph> jede Plattformversion, die Informationen zur Mitgliedschaft der einzelnen Plattformen enthält. Typ, der in Public Policy exportiert wurde.

Objektinhaberschaft und -labels

Bei der Anpassung der Richtlinien unter Android 8.0 und höher müssen die Eigentumsrechte klar definiert werden. für jedes Objekt, um Plattform und Anbieterrichtlinie voneinander zu trennen. Wenn beispielsweise die Anbieter-Labels /dev/foo und die Plattform, /dev/foo in einem nachfolgenden OTA-Update tritt ein undefiniertes Verhalten auf. Für SELinux, äußert sich dies als Labeling-Konflikt. Der Geräteknoten darf nur einen einzelnes Label, das in das zuletzt angewendete Label aufgelöst wird. Daraus ergeben sich folgende Konsequenzen:

• Für Prozesse, die Zugriff auf das nicht angewendete Label benötigen, den Zugriff auf die Ressource verlieren.
• Prozesse, die Zugriff auf die Datei erhalten, funktionieren möglicherweise nicht mehr, weil die Geräteknoten wurde erstellt.

Systemeigenschaften können auch Namenskonflikte verursachen, die zu undefiniertes Verhalten auf dem System (sowie für SELinux-Labeling). Kollisionen zwischen Plattform- und Anbieterlabels können für jedes Objekt auftreten, das ein SELinux einschließlich Eigenschaften, Diensten, Prozessen, Dateien und Sockets. Um dies zu vermeiden die Eigentumsrechte für diese Objekte klar zu definieren.

Neben Labelkonflikten können sich auch SELinux-Typ-/Attributnamen überschneiden. Eine Kollision von Typ/Attributnamen führt immer zu einem Richtlinien-Compiler-Fehler.

Namenstaktung für Typ/Attribut

SELinux lässt nicht mehrere Deklarationen desselben Typs bzw. desselben Attributs zu. Richtlinie mit doppelten Deklarationen kann die Kompilierung nicht erfolgreich sein. Um Typ- und Konflikte bezüglich Attributnamen haben, sollten alle Anbieterdeklarationen mit einem Namespace versehen sein. beginnend mit vendor_.

type foo, domain; → type vendor_foo, domain;

Systemeigenschaft und Prozessbeschriftung

Labelkonflikte vermeiden Sie am besten mit Attribut-Namespaces. Bis Plattform-Properties einfach identifizieren und Namenskonflikte bei der Umbenennung oder Exportierte Plattform-Properties hinzufügen, achten Sie darauf, dass alle Anbieter-Properties ihre eigene Präfixe:

Immobilienart	Zulässige Präfixe
Steuerelementeigenschaften	ctl.vendor. ctl.start$vendor. ctl.stop$vendor. init.svc.vendor.
schreibgeschützt	vendor.
schreibgeschützt	ro.vendor. ro.boot. ro.hardware.
dauerhaft	persist.vendor.

Anbieter können weiterhin ro.boot.* verwenden, das aus dem Kernel stammt cmdline) und ro.hardware.* (eine offensichtliche hardware-bezogene Eigenschaft).

Alle Anbieterdienste in Init-RC-Dateien sollten vendor. haben für Dienste in Init-RC-Dateien von Nicht-Systempartitionen. Ähnliche Regeln sind auf die SELinux-Labels für die Anbietereigenschaften (vendor_) angewendet für die Eigenschaften der Anbieter).

Eigentümerschaft von Dateien

Dateikollisionen zu vermeiden, ist schwierig, da Plattform und Anbieter stellen beide häufig Labels für alle Dateisysteme bereit. Anders als bei der Typbenennung Die Namensvermittlung von Dateien ist nicht praktikabel, da viele von ihnen vom Kernel. Folgen Sie der Benennungsanleitung für Dateisysteme, um diese Konflikte zu vermeiden. in diesem Abschnitt. Für Android 8.0 sind dies Empfehlungen ohne technische die Durchsetzung der Richtlinien. Künftig werden diese Empfehlungen durch das Vendor Test Suite (VTS):

System (/system)

Nur das System-Image muss Labels für /system-Komponenten haben über file_contexts, service_contexts usw. Wenn Labels Für /system werden in Richtlinie /vendor Komponenten hinzugefügt, ein OTA-Updates nur für Framework möglich.

Anbieter (/vendor)

Die AOSP SELinux-Richtlinie kennzeichnet bereits Teile der Partition vendor mit Labels mit denen die Plattform interagiert, wodurch das Schreiben von SELinux-Regeln für die Plattform Prozesse, die in der Lage sind, mit anderen zu kommunizieren und/oder auf Teile von vendor zuzugreifen -Partition an. Beispiele:

Pfad „/vendor“	Von der Plattform bereitgestelltes Label	Plattformprozesse abhängig vom Label
/vendor(/.*)?	vendor_file	Alle HAL-Clients im 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.

<ph type="x-smartling-placeholder">

</ph> * Weitere Beispiele finden Sie unter <ph type="x-smartling-placeholder"></ph> system/sepolicy/private/file_contexts

Daher müssen bestimmte Regeln eingehalten werden (durchgeführt neverallows), wenn Sie zusätzlichen Dateien in vendor Labels hinzufügen Partition:

• vendor_file muss das Standardlabel für alle Dateien in Partition vendor. Gemäß den Plattformrichtlinien ist dies für den Zugriff erforderlich Passthrough-HAL-Implementierungen.
• Alle neuen exec_types in der Partition vendor hinzugefügt über die SEPolicy des Anbieters muss das Attribut vendor_file_type haben. Dieses wird durch "Niezulassen" erzwungen.
• Vermeiden Sie Labels, um Konflikte mit zukünftigen Plattform-/Framework-Updates zu vermeiden. Andere Dateien als exec_types in der Partition vendor
• Alle Bibliotheksabhängigkeiten für durch AOSP identifizierte HALs desselben Prozesses müssen mit dem Label same_process_hal_file.

Procfs (/proc)

Dateien in /proc dürfen nur mit dem genfscon gekennzeichnet werden . In Android 7.0 werden sowohl die Plattform und Anbieter Richtlinie genfscon verwendet, um Dateien in procfs mit einem Label zu versehen.

Empfehlung:Nur Label für Plattformrichtlinien /proc. Wenn vendor-Prozesse Zugriff auf Dateien in /proc benötigen, die sind derzeit mit dem Standardlabel (proc) gekennzeichnet, Anbieterrichtlinie sollten sie nicht explizit beschriften, sondern stattdessen die allgemeine proc, um Regeln für Anbieterdomains hinzuzufügen. Dadurch kann die Plattform Updates zur Unterstützung zukünftiger Kernel-Schnittstellen, die über procfs und kennzeichnen Sie sie explizit nach Bedarf.

Debugfs (/sys/kernel/debug)

Debugfs kann sowohl in file_contexts als auch in genfscon In Android 7.0 bis Android 10 werden Plattform- und Anbieterlabel debugfs

In Android 11 kann debugfs nicht auf Geräten in der Produktion auf sie zugegriffen wird oder diese bereitgestellt werden. Gerätehersteller sollten debugfs entfernen.

Tracef (/sys/kernel/debug/tracing)

Tracefs kann sowohl in file_contexts als auch in genfscon In Android 7.0 werden nur die Plattformlabels tracefs

Empfehlung: Nur die Plattform darf tracefs kennzeichnen.

Sysfs (/sys)

Dateien in /sys können mit beiden Labels versehen werden: file_contexts und genfscon. In Android 7.0 verwenden Plattform und Anbieter file_contexts und genfscon, um Dateien mit Labels zu versehen sysfs

Empfehlung:Die Plattform kann das Label sysfs verwenden. Knoten, die nicht gerätespezifisch sind. Andernfalls kann nur der Anbieter Dateien mit Labels versehen.

tmpfs (/dev)

Dateien in /dev haben möglicherweise ein Label in file_contexts. In Hier finden Sie Android 7.0 sowohl Plattform- als auch Anbieter-Labeldateien.

Empfehlung:Der Anbieter kann nur Dateien mit Labels versehen, /dev/vendor (z.B. /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

Dateien in / haben möglicherweise ein Label in file_contexts. In Android 7.0, sowohl Plattform- als auch Anbieter-Labeldateien.

Empfehlung:Nur das System kann Dateien in / Labels hinzufügen.

Daten (/data)

Daten werden mithilfe einer Kombination aus file_contexts und seapp_contexts.

Empfehlung:Anbieter-Labeling außerhalb der Domain nicht zulassen /data/vendor Andere Teile des Produkts dürfen nur von der Plattform gekennzeichnet werden. /data

Kompatibilitätsattribute

Die SELinux-Richtlinie ist eine Interaktion zwischen Quell- und Zieltypen für bestimmte Objektklassen und Berechtigungen. Alle betroffenen Objekte (Prozesse, Dateien usw.) der SELinux-Richtlinie nur einen Typ haben, dieser kann jedoch mehrere Attribute.

Die Richtlinien werden hauptsächlich in Bezug auf die vorhandenen Typen verfasst:

allow source_type target_type:target_class permission(s);

Dies funktioniert, da bei der Richtlinienerstellung alle Arten von Kenntnissen berücksichtigt wurden. Sie können jedoch wenn in der Anbieter- und Plattformrichtlinie bestimmte Typen verwendet werden, und das Label einer Änderungen an Objekten nur in einer dieser Richtlinien vornehmen, kann die andere Richtlinien Richtlinien, auf die sich der zuvor gewährte oder verlorene Zugriff verlassen hat. Beispiel:

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

Mögliche Änderung in:

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

Die Anbieterrichtlinie bleibt unverändert, aber die v_domain würde den Zugriff aufgrund fehlender Richtlinien für die neue sysfs_A verlieren. Typ.

Durch das Definieren einer Richtlinie in Bezug auf Attribute können wir dem zugrunde liegenden Objekt -Typ mit einem Attribut, das der Richtlinie sowohl für die Plattform als auch Code des Anbieters. Dies kann für alle Typen durchgeführt werden, um effektiv eine attribute-policy, wobei konkrete Typen nie verwendet werden. In der Praxis Dies ist nur für die Richtlinienabschnitte erforderlich, die sich zwischen den Plattformen und Anbieter, die als öffentliche Plattformrichtlinien definiert und bereitgestellt werden. die als Teil der Anbieterrichtlinie erstellt wird.

Die Definition einer öffentlichen Richtlinie als versionierte Attribute erfüllt zwei Richtlinien Kompatibilitätsziele:

• Achten Sie darauf, dass der Anbietercode auch nach dem Plattformupdate funktioniert. Erreicht durch Hinzufügen von Attributen zu konkreten Typen für Objekte, die zu auf denen der Anbietercode basiert.
• Einstellung der Richtlinie: Erreicht durch eindeutige die Richtliniensätze in Attribute unterteilen, die entfernt werden können, sobald der Version, der sie entsprechen, wird nicht mehr unterstützt. Entwicklung kann können Sie auf der Plattform fortfahren, in dem Wissen, dass die alte Richtlinie noch in der und wird bei einem Upgrade automatisch entfernt.

Beschreibbarkeit von Richtlinien

Um das Ziel zu erreichen, keine Kenntnis bestimmter Versionsänderungen für Richtlinienentwicklung umfasst Android 8.0 eine Zuordnung zwischen Richtlinientypen und deren Attribute. Typ foo ist zugeordnet um foo_vN zuzuordnen, wobei N der Wert Version ausgerichtet. vN entspricht dem PLATFORM_SEPOLICY_VERSION-Build-Variable und hat das Format MM.NN, wobei MM der SDK-Nummer der Plattform entspricht NN ist eine plattformspezifische Version.

Attribute in öffentlichen Richtlinien sind nicht versioniert, sondern sind als API auf welche Plattform und Anbieterrichtlinie erstellt werden kann, um die Schnittstelle zwischen den beiden aufrechtzuerhalten. und Partitionen stabil sein. Sowohl Plattform- als auch Anbieterrichtlinien-Autoren können weiterhin Texte erstellen, in der heutigen Fassung.

Öffentliche Plattformrichtlinien, die als allow source_foo target_bar:class perm; exportiert wurden, sind in der Anbieterrichtlinie enthalten. Währenddessen Compilation (einschließlich der Version), wird er in die Richtlinie umgewandelt, die an die Zulieferunternehmen des Geräts (im transformierten Common Intermediate) Sprache (CIL):

 (allow source_foo_vN target_bar_vN (class (perm)))

Da die Anbieterrichtlinien der Plattform immer voraus sind, sollten Sie sich früheren Versionen. Die Plattformrichtlinien müssen jedoch wissen, wie weit der Anbieter zurückliegen darf. Richtlinie ist, Attribute für seine Typen einschließen und die Richtlinie festlegen, die versionierte Attribute ein.

Richtlinienunterschiede

Attribute werden automatisch erstellt, indem _vN am Ende hinzugefügt wird der einzelnen Typen geschieht nichts, ohne die Attribute den Typen der Version zuzuordnen. Unterschiede. Android unterhält eine Zuordnung zwischen Versionen für Attribute und einer die Zuordnung von Typen zu diesen Attributen. Dies erfolgt in der oben genannten Zuordnung Dateien mit Anweisungen wie (CIL):

(typeattributeset foo_vN (foo))

Plattformupgrades

Im folgenden Abschnitt werden Szenarien für Plattformupgrades beschrieben.

Gleiche Typen

Dieses Szenario tritt auf, wenn die Labels in den Richtlinienversionen von einem Objekt nicht geändert werden. Dies ist für die Quell- und Zieltypen gleich und gilt auch für /dev/binder mit dem Label binder_device in allen Veröffentlichungen. Sie wird in der transformierten Richtlinie so dargestellt:

binder_device_v1 … binder_device_vN

Beim Upgrade von v1 auf v2 muss die Plattformrichtlinie 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 Anbieterrichtlinie der Version 2 (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

Neue Typen

Dieses Szenario tritt auf, wenn auf der Plattform ein neuer beim Hinzufügen neuer Funktionen oder beim Härten von Richtlinien.

• Neue Funktion: Wenn der Typ ein Objekt mit einem Label versieht, das zuvor nicht existiert (z. B. ein neuer Serviceprozess), wurde der Anbietercode nicht zuvor direkt damit interagieren, damit keine entsprechende Richtlinie existiert. Das neue dem Typ entsprechendes Attribut besitzt kein Attribut in der vorherigen Version und benötigen daher keinen Eintrag in der Zuordnungsdatei, Version.
• Richtlinienhärtung. Wenn der Typ eine Richtlinie darstellt zur Härtung erforderlich ist, muss das neue Attribut „type“ auf eine Kette von Attributen zurückverweisen. entsprechend dem vorherigen (ähnlich dem vorherigen Beispiel, /sys/A von sysfs bis sysfs_A). Anbieter basiert auf einer Regel, die den Zugriff auf sysfs ermöglicht, und benötigt um diese Regel als Attribut des neuen Typs aufzunehmen.

Beim Upgrade von v1 auf v2 muss die Plattformrichtlinie 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 Anbieterrichtlinie der Version 2 (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. Dies kann passieren, wenn der zugrunde liegendes Objekt:

• Bleibt, erhält aber ein anderes Label.
• Sie wird von der Plattform entfernt.

Während der Richtlinienlockerung wird ein Typ entfernt und das Objekt mit diesem Typ gekennzeichnet erhält ein anderes, bereits vorhandenes Label. Dies stellt eine Zusammenführung von Attributzuordnungen: Der Anbietercode muss weiterhin auf die zugrunde liegende durch das Attribut ersetzen, das er zuvor hatte. Der Rest des Systems muss jedoch mit dem neuen Attribut auf sie zugreifen können.

Wenn das Attribut, auf das es umgestellt wurde, neu ist, ist die Umbenennung wie im Fall des neuen Typs, außer dass bei Verwendung eines vorhandenen Labels der Hinzufügen des alten Attributs neuer Typ würden andere Objekte, die ebenfalls als mit diesem Typ neu zugänglich sind. Das ist im Wesentlichen das, was der Plattform und gilt als akzeptabler Kompromiss Kompatibilität.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Beispielversion 1: Typen minimieren (sysfs_A entfernen)

Beim Upgrade von v1 auf v2 muss die Plattformrichtlinie 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 Anbieterrichtlinie der Version 2 (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Beispielversion 2: Vollständig entfernen (foo type)

Beim Upgrade von v1 auf v2 muss die Plattformrichtlinie 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 Anbieterrichtlinie der Version 2 (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

Neue Klasse/neue Berechtigungen

Dieses Szenario tritt auf, wenn bei einem Plattformupgrade neue Richtlinienkomponenten eingeführt werden die in früheren Versionen nicht vorhanden waren. So hat Android zum Beispiel servicemanager-Objektmanager, der die Elemente zum Hinzufügen, Suchen und Auflisten erstellt hat und Anbieter-Daemons, die sich beim servicemanager benötigte Berechtigungen, die nicht verfügbar. In Android 8.0 können neue Klassen und Richtlinien nur über die Plattformrichtlinie hinzugefügt werden. Berechtigungen.

Alle Domains zulassen, die durch eine Anbieterrichtlinie hätten erstellt oder erweitert werden können Um die neue Klasse ohne Hindernisse verwenden zu können, muss die Plattformrichtlinie einen ähnlich wie diese:

allow {domain -coredomain} *:new_class perm;

Möglicherweise ist sogar eine Richtlinie erforderlich, die den Zugriff für alle Benutzeroberflächen zulässt (öffentliche Richtlinie). um sicherzustellen, dass das Anbieter-Image Zugriff erhält. Wenn dies zu inakzeptablen (wie es bei Änderungen des Service Manager der Fall sein kann), möglicherweise erzwungen.

Kurs/Berechtigungen entfernt

Dieses Szenario tritt ein, wenn ein Objektmanager (z. B. der ZygoteConnection-Objektmanager) und sollte keine Probleme verursachen. Die Objekt-Manager-Klasse und Berechtigungen können in der Richtlinie definiert bleiben, bis die wird sie nicht mehr verwendet. Hierzu werden die Definitionen in die entsprechende Zuordnungsdatei ein.

Anbieteranpassung für neue/mit neuen Labels versehene Typen

Neue Anbietertypen stehen bei der Entwicklung von Anbieterrichtlinien im Mittelpunkt zur Beschreibung neuer Prozesse, Binärdateien, Geräte, Subsysteme und gespeicherter Daten. Als müssen Sie die Erstellung anbieterdefinierter Typen zulassen.

Da die Anbieterrichtlinie immer die älteste auf dem Gerät ist, ist es nicht nötig, Alle Anbietertypen werden in der Richtlinie automatisch in Attribute konvertiert. Die Plattform nicht auf die in der Anbieterrichtlinie beschrifteten Angaben basiert, da die Plattform Wissen darüber; Die Plattform stellt jedoch die Attribute und Typen, die zur Interaktion mit Objekten dieser Typen verwendet werden, z. B. domain, sysfs_type usw.). Damit die Plattform weiterhin korrekt mit diesen Objekten, den Attributen und Typen müssen angemessen angewendet werden und es müssen ggf. spezifische Regeln anpassbare Domains (z. B. init).

Attributänderungen für Android 9

Für Geräte, die auf Android 9 upgraden, können die folgenden Attribute verwendet werden, Geräte die Einführung mit Android 9 nicht gestattet ist.

Attribute mit Verstößen

Android 9 enthält die folgenden domainbezogenen Attribute:

• data_between_core_and_vendor_violators Attribut für alle Domains, die gegen die Anforderung verstoßen, dass keine Dateien freigegeben werden, indem Pfad zwischen vendor und coredomains. Plattform- und Anbieterprozesse sollten zur Kommunikation keine Dateien auf dem Laufwerk verwenden (instabiles ABI). Empfehlung: <ph type="x-smartling-placeholder">
  </ph>
  • Der Anbietercode sollte /data/vendor verwenden.
  • /data/vendor sollte nicht vom System verwendet werden.
• system_executes_vendor_violators Attribut für alle Systemdomains (außer init und shell domains) die gegen die Anforderung verstoßen, keine Anbieter-Binärprogramme auszuführen. Ausführung von Die Binärdateien des Anbieters haben eine instabile API. Die Plattform sollte keine Binärdateien des Anbieters ausführen . Empfehlung: <ph type="x-smartling-placeholder">
  </ph>
  • Solche Plattformabhängigkeiten von Anbieter-Binärdateien müssen sich hinter HIDL HALs befinden.

    ODER

  • coredomains, die Zugriff auf die Binärdateien des Anbieters benötigen, sollten wurden in die Anbieterpartition verschoben und sind daher nicht mehr coredomain.

Nicht vertrauenswürdige Attribute

Nicht vertrauenswürdige Apps, die beliebigen Code hosten, sollten keinen Zugriff auf HwBinder haben -Dienste, ausgenommen solche, die für den Zugriff über solche Apps als ausreichend sicher eingestuft werden (siehe „sichere Dienste“ unten). Dies sind die beiden Hauptgründe:

1. HwBinder-Server führen keine Clientauthentifizierung durch, da HIDL derzeit werden keine UID-Informationen des Aufrufers preisgegeben. Selbst wenn HIDL solche Daten preisgegeben hat, HwBinder-Dienste arbeiten entweder auf einer Ebene unterhalb der von Apps (wie HALs) oder sich für die Autorisierung nicht auf die App-Identität verlassen. Aus Sicherheitsgründen wird dass jeder HwBinder-Dienst alle Clients zur Durchführung von Vorgängen befugt ist, die im Rahmen des Dienstes angeboten werden.
2. HAL-Server (eine Teilmenge der HwBinder-Dienste) enthalten Code mit Häufigkeit von Sicherheitsproblemen als bei system/core Komponenten und Zugriff auf die unteren Ebenen des Stacks (bis hin zur Hardware) haben, immer mehr Möglichkeiten, das Android-Sicherheitsmodell zu umgehen.

Sichere Dienste

Zu den sicheren Diensten gehören:

• same_process_hwservice Diese Dienste werden (per Definition) ausgeführt in den Prozess des Clients und haben somit denselben Zugriff wie die Client-Domain in den der Prozess ausführt.
• coredomain_hwservice Diese Dienste stellen keine Risiken dar mit Grund 2 verknüpft ist.
• hal_configstore_ISurfaceFlingerConfigs Dieser Dienst ist die speziell für die Nutzung durch beliebige Domains entwickelt wurden.
• hal_graphics_allocator_hwservice Diese Vorgänge sind auch vom surfaceflinger Binder-Dienst angeboten, welche Apps zulässig sind um darauf zuzugreifen.
• hal_omx_hwservice Dies ist eine HwBinder-Version des mediacodec Binder-Dienst, auf die Apps zugreifen dürfen.
• hal_codec2_hwservice Dies ist eine neuere Version von hal_omx_hwservice.

Verwendbare Attribute

Alle hwservices, die nicht als sicher gelten, haben das Attribut untrusted_app_visible_hwservice. Die entsprechenden HAL-Server haben das Attribut untrusted_app_visible_halserver Geräte werden gestartet mit Android 9 DÜRFEN KEINES verwenden Attribut „untrusted“.

Empfehlung:

• Nicht vertrauenswürdige Apps sollten stattdessen mit einem Systemdienst kommunizieren, der mit dem Anbieter HIDL HAL. Apps können beispielsweise mit binderservicedomain und dann mit mediaserver kommunizieren (binderservicedomain) spricht wiederum mit hal_graphics_allocator.

  ODER

• Apps, die direkten Zugriff auf vendor HALs benötigen, sollten ihre eigenen eigene anbieterdefinierte sepolicy-Domain.

Dateiattributtests

Android 9 umfasst Build-Zeittests, mit denen sichergestellt wird, dass alle Dateien in bestimmten haben die entsprechenden Attribute (z. B. alle Dateien in sysfs haben das erforderliche Attribut sysfs_type).

Plattform-öffentliche Richtlinien

Die plattformweite öffentliche Richtlinie bildet den Kern der Einhaltung von Android 8.0. Architekturmodell zu erstellen, ohne einfach die Union der Plattformrichtlinien wahren zu müssen Version 1 und 2. Für Anbieter gilt eine Untergruppe von Plattformrichtlinien, verwendbare Typen und Attribute sowie Regeln zu diesen Typen und Attributen enthält. das dann Teil der Anbieterrichtlinie wird (d.h. vendor_sepolicy.cil.

Typen und Regeln werden in der vom Anbieter generierten Richtlinie automatisch übersetzt in attribute_vN, sodass alle von der Plattform bereitgestellten Typen sind versionierte Attribute, allerdings sind Attribute nicht versioniert. Die Plattform ist die konkreten Typen, die sie bereitstellt, in die entsprechenden Attribute verwenden, um sicherzustellen, dass die Anbieterrichtlinie weiterhin funktioniert und die Regeln die für eine bestimmte Version bereitgestellt werden. Die Kombination aus Die öffentliche Plattformrichtlinie und die Anbieterrichtlinie entsprechen der Android 8.0-Architektur. dass unabhängige Plattform- und Lieferanten-Builds möglich sind.

Zuordnung zu Attributketten

Wenn Sie Attribute für die Zuordnung zu Richtlinienversionen verwenden, wird ein Typ einem Attribut oder mehrere Attribute, wodurch sichergestellt wird, dass Objekte, die mit diesem Typ gekennzeichnet sind, über die ihren vorherigen Typen entsprechen.

Das Ziel, Versionsinformationen vor dem Richtlinienautor zu verbergen, bedeutet, die versionierten Attribute automatisch generiert und dem Typen geeignet sind. Bei statischen Typen ist dies unkompliziert: type_foo verweist auf type_foo_v1.

Bei einer Änderung des Objektlabels wie sysfs → sysfs_A oder mediaserver → audioserver, das Erstellen dieser Zuordnung ist nicht trivial sind (und in den Beispielen oben beschrieben). Administratoren für Plattformrichtlinien müssen bestimmen, wie die Zuordnung an Übergangspunkten für Objekte erstellt wird. erfordert, dass Sie die Beziehung zwischen Objekten und den ihnen zugewiesenen und bestimmen, wann dies geschieht. Aus Gründen der Abwärtskompatibilität die Komplexität auf der Plattformseite verwaltet werden muss. Sie ist die einzige Partition, das zu höheren Umsätzen führen kann.

Versionserhöhungen

Der Einfachheit halber veröffentlicht die Android-Plattform eine sepolicy-Version, wenn eine neue Release-Zweig ausgeschnitten. Wie oben beschrieben, ist die Versionsnummer in PLATFORM_SEPOLICY_VERSION und hat das Format MM.nn, Dabei entspricht MM dem SDK-Wert und nn ist ein privater Wert bewahrt in /platform/system/sepolicy. z. B. 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 sind nicht immer ganze Zahlen. Für Wenn z. B. ein MR auf eine Version stößt, erfordert eine inkompatible Änderung der system/sepolicy/public, aber nicht auf einen API-Bump, Version könnte lauten: vN.1. Die in der Entwicklung befindliche Version ist ein 10000.0, das beim Versand nie verwendet werden kann.

Bei einem Upgrade wird die älteste Android-Version möglicherweise eingestellt. Für die Eingabe bei eine Version eingestellt wird, kann Android die Anzahl der Geräte die diese Android-Version ausführen und noch eine wichtige Plattform erhält, Aktualisierungen. Wenn die Anzahl unter einem bestimmten Grenzwert liegt, wird diese Version eingestellt.

Auswirkungen auf die Leistung von mehrere Attribute

Wie unter https://github.com/SELinuxProject/cil/issues/9 beschrieben, viele Attribute, die einem Typ zugewiesen sind, führen zu Leistungsproblemen wenn ein Richtlinien-Cache-Fehler auftritt.

Es wurde bestätigt, dass es sich dabei um ein Problem bei Android handelt. Deshalb ändert sich wurden unter Android 8.0 vorgenommen, um Attribute zu entfernen, die vom Policy Compiler sowie das Entfernen nicht verwendeter Attribute. Diese Änderungen wurden behoben Leistungsabfälle.

Öffentliche Richtlinie (System_ext) und öffentliche Produktrichtlinien

Ab Android 11 dürfen system_ext und Produktpartitionen ihre festgelegten öffentlichen Typen in die Anbieterpartition exportieren. Plattform bewerten öffentlichen Richtlinien entsprechen, verwendet der Anbieter Typen und Regeln, die automatisch in die versionierten Attribute, z.B. von type in type_N, wobei N die Version ist der Plattform, auf der die Anbieterpartition basiert.

Wenn die system_ext- und Produktpartitionen auf derselben Plattformversion basieren N generiert das Build-System grundlegende Zuordnungsdateien zu system_ext/etc/selinux/mapping/N.cil und product/etc/selinux/mapping/N.cil, die Identitäten enthalten Zuordnungen von type zu type_N. Das Zulieferunternehmen kann Zugriff auf type mit dem versionierten Attribut type_N.

Wenn nur system_ext und Produktpartitionen aktualisiert werden, N bis N+1 (oder höher), während die bleibt der Anbieter bei N, verliert er möglicherweise den Zugriff auf den der system_ext- und Produktpartitionen. Um Ausfälle zu vermeiden, system_ext und Produktpartitionen sollten Zuordnungsdateien aus konkreten in type_N-Attribute ein. Jeder Partner für die Verwaltung der Zuordnungsdateien verantwortlich, N Anbieter mit N+1 (oder höher) system_ext und Produktpartitionen.

Dazu müssen Partner:

1. Kopieren Sie die generierten grundlegenden Zuordnungsdateien aus N system_ext und Produktaufteilungen zu ihrem Quellbaum hinzufügen.
2. Ergänzen Sie die Zuordnungsdateien nach Bedarf.
3. Installieren Sie die Zuordnungsdateien zu N+1 (oder höher) system_ext und Produktaufteilungen.

Beispiel: N system_ext hat genau eine öffentliche Typ mit dem Namen foo_type. Dann: system_ext/etc/selinux/mapping/N.cil in der system_ext-Partition N so aus:

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

Wenn bar_type zu „system_ext“ N+1 hinzugefügt wird und wenn bar_type foo_type für N Anbieter, N.cil kann aktualisiert werden von

(typeattributeset foo_type_N (foo_type))

(typeattributeset foo_type_N (foo_type bar_type))

und dann in der Partition N+1 von system_ext installiert. N Anbieter kann weiterhin auf N+1 zugreifen foo_type und bar_type von system_ext.

Labeling von SELinux-Kontexten

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

Dateikontexte

Mit Android 8.0 wurden die folgenden Änderungen für file_contexts eingeführt:

• Um zusätzlichen Kompilierungsaufwand auf dem Gerät während des Startvorgangs zu vermeiden, file_contexts existiert nicht mehr in Binärform. Stattdessen werden sie sind lesbare Textdateien mit regulären Ausdrücken wie {property, service}_contexts (vor Version 7.0).
• file_contexts werden auf zwei Dateien aufgeteilt: <ph type="x-smartling-placeholder">
  </ph>
  • plat_file_contexts
    • Android-Plattform file_context ohne gerätespezifische Labels, mit Ausnahme der Beschriftung von Teilen von /vendor-Partition, die genau mit dass die sepolicy-Dateien ordnungsgemäß funktionieren.
    • Muss sich in der Partition system befinden unter /system/etc/selinux/plat_file_contexts auf dem Gerät und von init beim Start zusammen mit dem Anbieter file_context.
  • vendor_file_contexts
    • Gerätespezifische file_context, erstellt aus einer Kombination file_contexts in den Verzeichnissen gefunden, auf die von verweist BOARD_SEPOLICY_DIRS im Boardconfig.mk-Dateien.
    • Muss hier installiert werden /vendor/etc/selinux/vendor_file_contexts Zoll vendor-Partition und wird von init am folgenden Ort geladen: zusammen mit der Plattform file_context.

Attributkontexte

In Android 8.0 wird property_contexts auf zwei Dateien aufgeteilt:

• plat_property_contexts
  • Android-Plattform property_context ohne gerätespezifischen Labels.
  • Muss sich in der Partition system befinden unter /system/etc/selinux/plat_property_contexts und geladen von init zu Beginn zusammen mit dem Anbieter property_contexts.
• vendor_property_contexts
  • Gerätespezifische property_context, erstellt aus einer Kombination property_contexts in den Verzeichnissen gefunden, auf die von verweist BOARD_SEPOLICY_DIRS im Gerät Boardconfig.mk-Dateien.
  • Muss sich in der Partition vendor befinden unter /vendor/etc/selinux/vendor_property_contexts und sein von init beim Start zusammen mit dem Bahnsteig geladen property_context

Dienstkontexte

In Android 8.0 wird service_contexts zwischen den folgenden Dateien:

• plat_service_contexts
  • Android-plattformspezifisches service_context für den servicemanager. service_context enthält keine gerätespezifischen Labels.
  • Muss sich in der Partition system befinden unter /system/etc/selinux/plat_service_contexts und geladen von servicemanager, zusammen mit dem Anbieter service_contexts.
• vendor_service_contexts
  • Gerätespezifische service_context, erstellt aus einer Kombination service_contexts in den Verzeichnissen gefunden, auf die von verweist BOARD_SEPOLICY_DIRS im Boardconfig.mk-Dateien.
  • Muss sich in der Partition vendor befinden unter /vendor/etc/selinux/vendor_service_contexts und geladen von servicemanager zu Beginn, zusammen mit der Plattform service_contexts.
  • Obwohl servicemanager beim Booten nach dieser Datei sucht, für ein vollständig konformes TREBLE-Gerät, das vendor_service_contexts DARF NICHT vorhanden sein. Das liegt daran, alle Interaktionen zwischen vendor und system Prozesse MÜSSEN durchlaufen hwservicemanager/hwbinder.
• plat_hwservice_contexts
  • Android-Plattform hwservice_context für hwservicemanager ohne gerätespezifische Labels.
  • Muss sich in der Partition system befinden unter /system/etc/selinux/plat_hwservice_contexts und geladen von hwservicemanager zusammen mit den vendor_hwservice_contexts.
• vendor_hwservice_contexts
  • Gerätespezifische hwservice_context, erstellt aus einer Kombination hwservice_contexts in den Verzeichnissen gefunden, auf die von verweist BOARD_SEPOLICY_DIRS im Boardconfig.mk-Dateien.
  • Muss sich in der Partition vendor befinden unter /vendor/etc/selinux/vendor_hwservice_contexts und sein von hwservicemanager beim Start zusammen mit dem plat_service_contexts.
• vndservice_contexts
  • Gerätespezifisches service_context für den vndservicemanager erstellt durch Kombination vndservice_contexts in den Verzeichnissen gefunden, auf die von verweist BOARD_SEPOLICY_DIRS im Boardconfig.mk
  • Diese Datei muss sich in der Partition vendor unter folgendem Pfad befinden: /vendor/etc/selinux/vndservice_contexts und geladen von vndservicemanager zu beginnen.

SeApp-Kontexte

In Android 8.0 wird seapp_contexts auf zwei Dateien aufgeteilt:

• plat_seapp_contexts
  • Android-Plattform seapp_context ohne gerätespezifische Änderungen.
  • Muss sich in der Partition system befinden unter /system/etc/selinux/plat_seapp_contexts.
• vendor_seapp_contexts
  • Gerätespezifische Erweiterung für Plattform seapp_context entwickelt durch Kombinieren von seapp_contexts aus den Verzeichnissen BOARD_SEPOLICY_DIRS in der Boardconfig.mk-Dateien.
  • Muss sich in der Partition vendor befinden unter /vendor/etc/selinux/vendor_seapp_contexts.

MAC-Berechtigungen

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

• Gleis mac_permissions.xml <ph type="x-smartling-placeholder">
  </ph>
  • Android-Plattform mac_permissions.xml ohne gerätespezifischen Änderungen vornehmen.
  • Muss sich in der Partition system befinden unter /system/etc/selinux/.
• Nicht-Plattform mac_permissions.xml <ph type="x-smartling-placeholder">
  </ph>
  • Gerätespezifische Plattformerweiterung mac_permissions.xml erstellt aus mac_permissions.xml in den Verzeichnissen gefunden, auf die von verwiesen wird BOARD_SEPOLICY_DIRS im Boardconfig.mk Dateien.
  • Muss sich in der Partition vendor befinden unter /vendor/etc/selinux/.