Anpassen von SELinux

Nachdem Sie die Basisebene der SELinux-Funktionalität integriert und die Ergebnisse gründlich analysiert haben, können Sie Ihre eigenen Richtlinieneinstellungen hinzufügen, um Ihre Anpassungen am Android-Betriebssystem abzudecken. Diese Richtlinien müssen weiterhin die Anforderungen des Android-Kompatibilitätsprogramms erfüllen und dürfen die Standardeinstellungen von SELinux nicht entfernen.

Hersteller sollten die bestehende SELinux-Richtlinie nicht entfernen. Andernfalls besteht die Gefahr, dass die Android SELinux-Implementierung und die von ihr verwalteten Anwendungen beschädigt werden. Dazu gehören Anwendungen von Drittanbietern, die wahrscheinlich verbessert werden müssen, um konform und betriebsbereit zu sein. Anwendungen dürfen keine Änderungen erfordern, um weiterhin auf SELinux-fähigen Geräten zu funktionieren.

Denken Sie beim Anpassen von SELinux an Folgendes:

  • Schreiben Sie eine SELinux-Richtlinie für alle neuen Daemons
  • Verwenden Sie bei Bedarf vordefinierte Domänen
  • Weisen Sie jedem Prozess, der als init -Dienst erzeugt wird, eine Domäne zu
  • Machen Sie sich mit den Makros vertraut, bevor Sie Richtlinien schreiben
  • Senden Sie Änderungen an der Kernrichtlinie an AOSP

Und denken Sie daran, Folgendes nicht zu tun:

  • Erstellen Sie eine inkompatible Richtlinie
  • Ermöglichen Sie die Anpassung der Endbenutzerrichtlinien
  • Erlauben Sie die Anpassung von MDM-Richtlinien
  • Erschrecken Sie Benutzer mit Richtlinienverstößen
  • Hintertüren hinzufügen

Spezifische Anforderungen finden Sie im Abschnitt „Kernel-Sicherheitsfunktionen“ des Dokuments „Definition der Android-Kompatibilität“ .

SELinux verwendet einen Whitelist-Ansatz, was bedeutet, dass jeder Zugriff in der Richtlinie explizit erlaubt werden muss, um gewährt zu werden. Da die standardmäßige SELinux-Richtlinie von Android das Android Open Source Project bereits unterstützt, müssen Sie die SELinux-Einstellungen in keiner Weise ändern. Wenn Sie die SELinux-Einstellungen anpassen, achten Sie sorgfältig darauf, bestehende Anwendungen nicht zu beschädigen. Um zu beginnen:

  1. Verwenden Sie den neuesten Android-Kernel .
  2. Übernehmen Sie das Prinzip der geringsten Privilegien .
  3. Adressieren Sie nur Ihre eigenen Ergänzungen zu Android. Die Standardrichtlinie funktioniert automatisch mit der Codebasis des Android Open Source Project .
  4. Unterteilen Sie Softwarekomponenten in Module, die einzelne Aufgaben ausführen.
  5. Erstellen Sie SELinux-Richtlinien, die diese Aufgaben von nicht verwandten Funktionen isolieren.
  6. Legen Sie diese Richtlinien in *.te Dateien (die Erweiterung für SELinux-Richtlinienquelldateien) im Verzeichnis /device/ manufacturer / device-name /sepolicy und verwenden Sie BOARD_SEPOLICY -Variablen, um sie in Ihren Build einzubinden.
  7. Machen Sie neue Domains zunächst freizügig. Dies erfolgt durch die Verwendung einer permissiven Deklaration in der .te Datei der Domain.
  8. Analysieren Sie die Ergebnisse und verfeinern Sie Ihre Domänendefinitionen.
  9. Entfernen Sie die permissive Deklaration, wenn in Userdebug-Builds keine weiteren Ablehnungen auftreten.

Nachdem Sie Ihre SELinux-Richtlinienänderung integriert haben, fügen Sie Ihrem Entwicklungsworkflow einen Schritt hinzu, um die SELinux-Kompatibilität in Zukunft sicherzustellen. In einem idealen Softwareentwicklungsprozess ändert sich die SELinux-Richtlinie nur, wenn sich das Softwaremodell und nicht die tatsächliche Implementierung ändert.

Wenn Sie mit der Anpassung von SELinux beginnen, überprüfen Sie zunächst Ihre Ergänzungen zu Android. Wenn Sie eine Komponente hinzugefügt haben, die eine neue Funktion ausführt, stellen Sie sicher, dass die Komponente die Sicherheitsrichtlinie von Android sowie alle damit verbundenen, vom OEM erstellten Richtlinien erfüllt, bevor Sie den Durchsetzungsmodus aktivieren.

Um unnötige Probleme zu vermeiden, ist es besser, zu weit gefasst und zu kompatibel zu sein, als zu restriktiv und inkompatibel, was zu fehlerhaften Gerätefunktionen führt. Wenn Ihre Änderungen hingegen anderen zugute kommen, sollten Sie die Änderungen an der Standard-SELinux-Richtlinie als Patch einreichen. Wenn der Patch auf die Standardsicherheitsrichtlinie angewendet wird, müssen Sie diese Änderung nicht bei jeder neuen Android-Version vornehmen.

Beispielrichtlinienerklärungen

SELinux basiert auf der Computersprache M4 und unterstützt daher eine Vielzahl von Makros, um Zeit zu sparen.

Im folgenden Beispiel wird allen Domänen Lese- oder Schreibzugriff auf /dev/null und Lesezugriff auf /dev/zero gewährt.

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Dieselbe Anweisung kann mit SELinux *_file_perms Makros (Kurzschrift) geschrieben werden:

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Beispielrichtlinie

Hier ist eine vollständige Beispielrichtlinie für DHCP, die wir im Folgenden untersuchen:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Sehen wir uns das Beispiel genauer an:

In der ersten Zeile, der Typdeklaration, erbt der DHCP-Daemon von der Basissicherheitsrichtlinie ( domain ). Aus den vorherigen Anweisungsbeispielen geht hervor, dass DHCP von /dev/null lesen und schreiben kann.

In der zweiten Zeile wird DHCP als permissive Domäne identifiziert.

In der Zeile init_daemon_domain(dhcp) gibt die Richtlinie an, dass DHCP von init erzeugt wird und mit ihm kommunizieren darf.

In der Zeile net_domain(dhcp) ermöglicht die Richtlinie DHCP, allgemeine Netzwerkfunktionen der net zu nutzen, z. B. das Lesen und Schreiben von TCP-Paketen, die Kommunikation über Sockets und die Durchführung von DNS-Anfragen.

In der Zeile allow dhcp proc_net:file write; , besagt die Richtlinie, dass DHCP in bestimmte Dateien in /proc schreiben kann. Diese Zeile demonstriert die feinkörnige Dateikennzeichnung von SELinux. Es verwendet die Bezeichnung proc_net , um den Schreibzugriff nur auf die Dateien unter /proc/sys/net zu beschränken.

Der letzte Block des Beispiels beginnt allow dhcp netd:fd use; stellt dar, wie Anwendungen miteinander interagieren dürfen. Die Richtlinie besagt, dass DHCP und netd über Dateideskriptoren, FIFO-Dateien, Datagramm-Sockets und UNIX-Stream-Sockets miteinander kommunizieren dürfen. DHCP darf die Datagramm-Sockets und UNIX-Stream-Sockets nur lesen und schreiben, sie jedoch nicht erstellen oder öffnen.

Verfügbare Steuerelemente

Klasse Erlaubnis
Datei
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
Verzeichnis
add_name remove_name reparent search rmdir open audit_access execmod
Steckdose
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
Dateisystem
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
Verfahren
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
Sicherheit
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
Fähigkeit
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

MEHR

UND MEHR

Neverallow-Regeln

SELinux- neverallow Regeln verbieten Verhalten, das niemals auftreten sollte. Mit Kompatibilitätstests werden SELinux- neverallow Regeln jetzt geräteübergreifend durchgesetzt.

Die folgenden Richtlinien sollen Herstellern dabei helfen, Fehler im Zusammenhang mit neverallow Regeln bei der Anpassung zu vermeiden. Die hier verwendeten Regelnummern entsprechen Android 5.1 und können sich je nach Veröffentlichung ändern.

Regel 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Siehe die Manpage für ptrace . Die sys_ptrace Fähigkeit gewährt die Möglichkeit, jeden Prozess zu ptrace , was ein hohes Maß an Kontrolle über andere Prozesse ermöglicht und nur zu bestimmten Systemkomponenten gehören sollte, wie in der Regel beschrieben. Der Bedarf an dieser Funktion weist oft auf das Vorhandensein von etwas hin, das nicht für benutzerorientierte Builds gedacht ist, oder auf Funktionen, die nicht benötigt werden. Entfernen Sie die unnötige Komponente.

Regel 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Diese Regel soll die Ausführung beliebigen Codes auf dem System verhindern. Insbesondere wird behauptet, dass nur Code auf /system ausgeführt wird, was Sicherheitsgarantien dank Mechanismen wie verifiziertem Booten ermöglicht. Wenn ein Problem mit dieser neverallow Regel auftritt, besteht die beste Lösung häufig darin, den fehlerhaften Code in die Partition /system zu verschieben.

Anpassen von SEPolicy in Android 8.0+

Dieser Abschnitt enthält Richtlinien für die SELinux-Richtlinie des Anbieters in Android 8.0 und höher, einschließlich Details zu SEPolicy und SEPolicy-Erweiterungen des Android Open Source Project (AOSP). Weitere Informationen dazu, wie die SELinux-Richtlinie über Partitionen und Android-Versionen hinweg kompatibel gehalten wird, finden Sie unter Kompatibilität .

Richtlinienplatzierung

In Android 7.0 und früher konnten Gerätehersteller Richtlinien zu BOARD_SEPOLICY_DIRS hinzufügen, einschließlich einer Richtlinie, die die AOSP-Richtlinie für verschiedene Gerätetypen erweitern soll. In Android 8.0 und höher wird durch das Hinzufügen einer Richtlinie zu BOARD_SEPOLICY_DIRS die Richtlinie nur im Anbieter-Image platziert.

In Android 8.0 und höher sind Richtlinien an den folgenden Orten in AOSP vorhanden:

  • system/sepolicy/public . Enthält Richtlinien, die zur Verwendung in herstellerspezifischen Richtlinien exportiert wurden. Alles fließt in die Android 8.0 -Kompatibilitätsinfrastruktur ein. Die öffentliche Richtlinie soll über alle Releases hinweg bestehen bleiben, sodass Sie alles, was /public in Ihre benutzerdefinierte Richtlinie aufnehmen können. Aus diesem Grund ist die Art der Richtlinie, die in /public platziert werden kann, stärker eingeschränkt. Betrachten Sie dies als die exportierte Richtlinien-API der Plattform: Alles, was sich mit der Schnittstelle zwischen /system und /vendor befasst, gehört hierher.
  • system/sepolicy/private . Enthält Richtlinien, die für das Funktionieren des Systemabbilds erforderlich sind, von denen die Anbieter-Image-Richtlinie jedoch keine Kenntnis haben sollte.
  • system/sepolicy/vendor . Enthält Richtlinien für Komponenten, die in /vendor abgelegt werden, aber im Kernplattformbaum vorhanden sind (keine gerätespezifischen Verzeichnisse). Dies ist ein Artefakt der Unterscheidung des Build-Systems zwischen Geräten und globalen Komponenten. Konzeptionell ist dies Teil der unten beschriebenen gerätespezifischen Richtlinie.
  • Gerät/ manufacturer / device-name /sepolicy . Enthält eine gerätespezifische Richtlinie. Beinhaltet auch Geräteanpassungen an die Richtlinie, die in Android 8.0 und höher der Richtlinie für Komponenten im Anbieter-Image entspricht.

In Android 11 und höher können system_ext- und Produktpartitionen auch partitionsspezifische Richtlinien enthalten. system_ext- und Produktrichtlinien sind ebenfalls in öffentliche und private Richtlinien unterteilt, und Anbieter können die öffentlichen Richtlinien von system_ext und Produkt wie die Systemrichtlinie verwenden.

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Enthält Richtlinien, die zur Verwendung in herstellerspezifischen Richtlinien exportiert wurden. Installiert auf der system_ext-Partition.
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Enthält Richtlinien, die für das Funktionieren des system_ext-Images erforderlich sind, von denen die Anbieter-Image-Richtlinien jedoch keine Kenntnis haben sollten. Installiert auf der system_ext-Partition.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS . Enthält Richtlinien, die zur Verwendung in herstellerspezifischen Richtlinien exportiert wurden. Auf der Produktpartition installiert.
  • PRODUCT_PRIVATE_SEPOLICY_DIRS . Enthält Richtlinien, die für das Funktionieren des Produktbilds erforderlich sind, von denen die Anbieter-Bildrichtlinie jedoch keine Kenntnis haben sollte. Auf der Produktpartition installiert.
Hinweis: Wenn GSI verwendet wird, werden die system_ext- und Produktpartitionen des OEM nicht gemountet. Die Regeln in der Anbieter-Separatrichtlinie, die system_ext und die öffentliche Produktrichtlinie des OEM verwendet, werden zu NOP, da die OEM-spezifischen Typdefinitionen fehlen.
Hinweis: Seien Sie besonders vorsichtig, wenn Sie system_ext und öffentliche Produktrichtlinien verwenden. Öffentliche Richtlinien fungieren als exportierte API zwischen system_ext/product und Anbieter. Partner sollen Kompatibilitätsprobleme selbst lösen.

Unterstützte Richtlinienszenarien

Auf Geräten, die mit Android 8.0 und höher gestartet werden, muss das Anbieter-Image mit dem OEM-System-Image und dem von Google bereitgestellten Referenz-AOSP-System-Image funktionieren (und CTS für dieses Referenz-Image übergeben). Diese Anforderungen stellen eine saubere Trennung zwischen dem Framework und dem Herstellercode sicher. Solche Geräte unterstützen die folgenden Szenarien.

Nur-Anbieter-Image-Erweiterungen

Beispiel : Hinzufügen eines neuen Dienstes zu vndservicemanager aus dem Anbieter-Image, der Prozesse aus dem Anbieter-Image unterstützt.

Fügen Sie wie bei Geräten, die mit früheren Android-Versionen gestartet werden, gerätespezifische Anpassungen in device/ manufacturer / device-name /sepolicy hinzu. Die neue Richtlinie, die regelt, wie Anbieterkomponenten (nur) mit anderen Anbieterkomponenten interagieren , sollte Typen umfassen, die nur in device/ manufacturer / device-name /sepolicy vorhanden sind . Die hier geschriebene Richtlinie ermöglicht das Funktionieren des Codes des Anbieters, wird nicht als Teil eines reinen Framework-OTA aktualisiert und ist in der kombinierten Richtlinie auf einem Gerät mit dem Referenz-AOSP-System-Image vorhanden.

Hersteller-Image-Unterstützung für die Arbeit mit AOSP

Beispiel : Hinzufügen eines neuen Prozesses (registriert bei hwservicemanager aus dem Anbieter-Image), der einen AOSP-definierten HAL implementiert.

Führen Sie wie bei Geräten, die mit früheren Android-Versionen gestartet werden, eine gerätespezifische Anpassung unter device/ manufacturer / device-name /sepolicy durch. Die als Teil von system/sepolicy/public/ exportierte Richtlinie steht zur Verwendung zur Verfügung und wird als Teil der Anbieterrichtlinie versendet. Typen und Attribute aus der öffentlichen Richtlinie können in neuen Regeln verwendet werden, die Interaktionen mit den neuen herstellerspezifischen Bits vorschreiben, vorbehaltlich der bereitgestellten neverallow Einschränkungen. Wie im Nur-Anbieter-Fall wird die neue Richtlinie hier nicht als Teil eines reinen Framework-OTA aktualisiert und ist in der kombinierten Richtlinie auf einem Gerät mit dem Referenz-AOSP-System-Image vorhanden.

Nur System-Image-Erweiterungen

Beispiel : Hinzufügen eines neuen Dienstes (registriert bei servicemanager), auf den nur andere Prozesse aus dem Systemabbild zugreifen.

Fügen Sie diese Richtlinie zu system/sepolicy/private hinzu. Sie können zusätzliche Prozesse oder Objekte hinzufügen, um die Funktionalität in einem Partnersystem-Image zu ermöglichen, vorausgesetzt, dass diese neuen Bits nicht mit neuen Komponenten auf dem Anbieter-Image interagieren müssen (insbesondere müssen solche Prozesse oder Objekte ohne Richtlinien aus dem Anbieter-Image vollständig funktionieren). . Die von system/sepolicy/public exportierte Richtlinie ist hier ebenso verfügbar wie für Nur-Anbieter-Image-Erweiterungen. Diese Richtlinie ist Teil des Systemabbilds und könnte in einem reinen Framework-OTA aktualisiert werden, ist jedoch nicht vorhanden, wenn das Referenz-AOSP-Systemabbild verwendet wird.

Anbieter-Image-Erweiterungen, die erweiterte AOSP-Komponenten bereitstellen

Beispiel: Ein neues, nicht-AOSP-HAL zur Verwendung durch erweiterte Clients, die auch im AOSP-Systemabbild vorhanden sind (z. B. ein erweiterter system_server).

Die Richtlinie für die Interaktion zwischen System und Anbieter muss im Verzeichnis device/ manufacturer / device-name /sepolicy enthalten sein, das auf der Anbieterpartition bereitgestellt wird. Dies ähnelt dem obigen Szenario des Hinzufügens von Hersteller-Image-Unterstützung, um mit dem Referenz-AOSP-Image zu arbeiten, mit der Ausnahme, dass die geänderten AOSP-Komponenten möglicherweise auch zusätzliche Richtlinien erfordern, um ordnungsgemäß mit dem Rest der Systempartition zu funktionieren (was in Ordnung ist, solange sie noch vorhanden sind). über die öffentlichen AOSP-Typenschilder verfügen).

Die Richtlinie für die Interaktion öffentlicher AOSP-Komponenten mit Nur-System-Image-Erweiterungen sollte in system/sepolicy/private enthalten sein.

System-Image-Erweiterungen, die nur auf AOSP-Schnittstellen zugreifen

Beispiel: Ein neuer Nicht-AOSP-Systemprozess muss auf eine HAL zugreifen, auf die AOSP angewiesen ist.

Dies ähnelt dem Beispiel für die Nur-System-Image-Erweiterung , außer dass neue Systemkomponenten über die system/vendor interagieren können. Die Richtlinie für die neue Systemkomponente muss in system/sepolicy/private abgelegt werden. Dies ist akzeptabel, sofern sie über eine von AOSP bereits in system/sepolicy/public eingerichtete Schnittstelle erfolgt (dh die für die Funktionalität erforderlichen Typen und Attribute sind vorhanden). Während die Richtlinie in die gerätespezifische Richtlinie aufgenommen werden könnte, wäre sie aufgrund einer Nur-Framework-Aktualisierung nicht in der Lage, andere system/sepolicy/private zu verwenden oder sich (in irgendeiner Weise, die sich auf die Richtlinie auswirkt) zu ändern. Die Richtlinie kann in einem reinen Framework-OTA geändert werden, ist jedoch nicht vorhanden, wenn ein AOSP-System-Image verwendet wird (das auch nicht über die neue Systemkomponente verfügt).

Anbieter-Image-Erweiterungen, die neue Systemkomponenten bedienen

Beispiel: Hinzufügen eines neuen Nicht-AOSP-HAL zur Verwendung durch einen Clientprozess ohne AOSP-Analogon (und erfordert daher eine eigene Domäne).

Ähnlich wie im AOSP-extensions-Beispiel muss die Richtlinie für Interaktionen zwischen System und Anbieter im Verzeichnis device/ manufacturer / device-name /sepolicy auf der Vendor-Partition abgelegt werden (um sicherzustellen, dass die Systemrichtlinie keine Kenntnis von herstellerspezifischen Details hat). Sie können neue öffentliche Typen hinzufügen, die die Richtlinie in system/sepolicy/public erweitern. Dies sollte nur zusätzlich zur bestehenden AOSP-Richtlinie erfolgen, dh die öffentliche AOSP-Richtlinie darf nicht entfernt werden. Die neuen öffentlichen Typen können dann für Richtlinien in system/sepolicy/private und in device/ manufacturer / device-name /sepolicy verwendet werden.

Bedenken Sie, dass jede Ergänzung zu system/sepolicy/public die Komplexität erhöht, indem eine neue Kompatibilitätsgarantie offengelegt wird, die in einer Zuordnungsdatei nachverfolgt werden muss und anderen Einschränkungen unterliegt. In system/sepolicy/public dürfen nur neue Typen und entsprechende Zulassungsregeln hinzugefügt werden. Attribute und andere Richtlinienanweisungen werden nicht unterstützt. Darüber hinaus können neue öffentliche Typen nicht verwendet werden, um Objekte in der /vendor Richtlinie direkt zu kennzeichnen.

Nicht unterstützte Richtlinienszenarien

Geräte, die mit Android 8.0 und höher gestartet werden, unterstützen das folgende Richtlinienszenario und die folgenden Beispiele nicht.

Zusätzliche Erweiterungen des System-Images, die nach einem reinen Framework-OTA eine Berechtigung für neue Anbieter-Image-Komponenten benötigen

Beispiel: Ein neuer Nicht-AOSP-Systemprozess, der eine eigene Domäne erfordert, wird in der nächsten Android-Version hinzugefügt und benötigt Zugriff auf eine neue Nicht-AOSP-HAL.

Ähnlich wie bei der Interaktion zwischen neuen (nicht AOSP-)Systemen und Anbieterkomponenten , mit der Ausnahme, dass der neue Systemtyp in einem reinen Framework-OTA eingeführt wird. Obwohl der neue Typ zur Richtlinie in system/sepolicy/public hinzugefügt werden könnte, kennt die bestehende Anbieterrichtlinie den neuen Typ nicht, da sie nur die öffentliche Richtlinie des Android 8.0-Systems verfolgt. AOSP handhabt dies, indem es vom Anbieter bereitgestellte Ressourcen über ein Attribut (z. B. hal_foo Attribut) verfügbar macht. Da jedoch Attributpartnererweiterungen in system/sepolicy/public nicht unterstützt werden, ist diese Methode für die Anbieterrichtlinie nicht verfügbar. Der Zugriff muss über einen zuvor vorhandenen öffentlichen Typ erfolgen.

Beispiel: Eine Änderung an einem Systemprozess (AOSP oder Nicht-AOSP) muss die Art und Weise ändern, wie er mit neuen Nicht-AOSP-Anbieterkomponenten interagiert.

Die Richtlinie für das Systemabbild muss ohne Kenntnis spezifischer Anbieteranpassungen geschrieben werden. Richtlinien für bestimmte Schnittstellen in AOSP werden daher über Attribute in system/sepolicy/public offengelegt, sodass sich Anbieterrichtlinien für zukünftige Systemrichtlinien entscheiden können, die diese Attribute verwenden. Allerdings werden Attributerweiterungen in system/sepolicy/public nicht unterstützt , daher müssen alle Richtlinien, die vorschreiben, wie die Systemkomponenten mit neuen Anbieterkomponenten interagieren (und die nicht durch bereits in AOSP system/sepolicy/public vorhandene Attribute gehandhabt werden), in device/ manufacturer / device-name /sepolicy sein. device/ manufacturer / device-name /sepolicy . Dies bedeutet, dass Systemtypen den Zugriff auf Anbietertypen im Rahmen eines reinen Framework-OTA nicht ändern können.