SELinux anpassen

Nachdem Sie die grundlegenden SELinux-Funktionen eingebunden und die Ergebnisse gründlich analysiert haben, können Sie eigene 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 Standard-SELinux-Einstellungen nicht entfernen.

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

Beachten Sie beim Anpassen von SELinux Folgendes:

  • SELinux-Richtlinie für alle neuen Daemons schreiben
  • Verwenden Sie nach Bedarf vordefinierte Domains.
  • Weisen Sie jedem Prozess, der als init-Dienst erstellt wurde, eine Domain zu
  • Makros kennenlernen, bevor Sie eine Richtlinie erstellen
  • Änderungen an der Hauptrichtlinie an AOSP senden

Und nicht vergessen:

  • Inkompatible Richtlinie erstellen
  • Anpassung der Endnutzerrichtlinie zulassen
  • Anpassungen von MDM-Richtlinien zulassen
  • Nutzer mit Richtlinienverstößen verängstigen
  • Backdoors hinzufügen

Spezifische Anforderungen finden Sie im Abschnitt Kernel Security Features des Dokuments Android Compatibility Definition.

SELinux verwendet einen Whitelisting-Ansatz. Das bedeutet, dass der gesamte Zugriff in der Richtlinie ausdrücklich zugelassen werden muss, damit er gewährt werden kann. Da die SELinux-Standardrichtlinie von Android bereits das Android-Open-Source-Projekt unterstützt, müssen Sie die SELinux-Einstellungen in keiner Weise ändern. Wenn Sie die SELinux-Einstellungen anpassen, achten Sie darauf, dass vorhandene Apps nicht beeinträchtigt werden. So gehts:

  1. Verwenden Sie den neuesten Android-Kernel.
  2. Berücksichtigen Sie das Prinzip der geringsten Berechtigung.
  3. Beziehen Sie sich nur auf Ihre eigenen Ergänzungen zu Android. Die Standardrichtlinie funktioniert automatisch mit der Codebasis des Android Open Source Project.
  4. Softwarekomponenten in Module unterteilen, die einzelne Aufgaben ausführen.
  5. Erstellen Sie SELinux-Richtlinien, um diese Aufgaben von nicht verwandten Funktionen zu isolieren.
  6. Legen Sie diese Richtlinien in *.te-Dateien (die Erweiterung für SELinux-Quelldateien von Richtlinien) im Verzeichnis /device/manufacturer/device-name/sepolicy ab und verwenden Sie BOARD_SEPOLICY-Variablen, um sie in Ihren Build aufzunehmen.
  7. Legen Sie für neue Domains anfangs eine permissive Einstellung fest. Dazu wird in der .te-Datei der Domain eine permissive Deklaration verwendet.
  8. Analysieren Sie die Ergebnisse und verfeinern Sie Ihre Domaindefinitionen.
  9. Entfernen Sie die permissive Deklaration, wenn in userdebug-Builds keine weiteren Ablehnungen mehr angezeigt werden.

Nachdem Sie die SELinux-Richtlinienänderung integriert haben, fügen Sie Ihrem Entwicklungsablauf einen Schritt hinzu, um die SELinux-Kompatibilität in Zukunft zu gewährleisten. Im Idealfall ändern sich die SELinux-Richtlinien nur, wenn sich das Softwaremodell ändert, nicht die tatsächliche Implementierung.

Bevor Sie mit der Anpassung von SELinux beginnen, prüfen Sie zuerst Ihre Ergänzungen zu Android. Wenn Sie eine Komponente hinzugefügt haben, die eine neue Funktion ausführt, achten Sie darauf, dass die Komponente der Sicherheitsrichtlinie von Android sowie allen zugehörigen Richtlinien des OEM entspricht, bevor Sie den Erzwingungsmodus 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 Funktionsstörungen des Geräts führt. Wenn Ihre Änderungen hingegen auch anderen zugutekommen, 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.

Beispiel für Richtlinienanweisungen

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

Im folgenden Beispiel erhalten alle Domains Lese- und Schreibzugriff auf /dev/null und Lesezugriff auf /dev/zero.

# 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 };

Diese Anweisung kann auch mit SELinux-*_file_perms-Makros (Kurzzeichen) 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 unten 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 an:

In der ersten Zeile, der Typdeklaration, übernimmt der DHCP-Daemon die Einstellungen der grundlegenden Sicherheitsrichtlinie (domain). Aus den vorherigen Beispielen mit Anweisungen kann DHCP aus /dev/null lesen und schreiben.

In der zweiten Zeile wird DHCP als freizügige Domain identifiziert.

In der Zeile init_daemon_domain(dhcp) wird in der Richtlinie angegeben, dass DHCP von init gestartet wird und mit diesem kommunizieren darf.

In der Zeile net_domain(dhcp) erlaubt die Richtlinie, dass DHCP allgemeine Netzwerkfunktionen der Domain net verwenden kann, um beispielsweise TCP-Pakete zu lesen und zu schreiben, über Sockets zu kommunizieren und DNS-Anfragen auszuführen.

In der Zeile allow dhcp proc_net:file write; gibt die Richtlinie an, dass DHCP in bestimmte Dateien in /proc schreiben kann. Diese Zeile veranschaulicht die detaillierte Dateibeschriftung von SELinux. Dabei wird das Label proc_net verwendet, um den Schreibzugriff auf die Dateien unter /proc/sys/net zu beschränken.

Der letzte Block des Beispiels, der mit allow dhcp netd:fd use; beginnt, zeigt, wie Apps miteinander interagieren dürfen. Die Richtlinie besagt, dass DHCP und netd über Dateideskriptoren, FIFO-Dateien, Datagram-Sockets und UNIX-Stream-Sockets miteinander kommunizieren können. DHCP darf nur in die Datagram-Sockets und UNIX-Stream-Sockets lesen und daraus schreiben, sie aber nicht erstellen oder öffnen.

Verfügbare Steuerelemente

Klasse Berechtigung
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
Socket 
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
filesystem 
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
Prozess 
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
Capability 
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

Niezulassen-Regeln

SELinux-neverallow-Regeln verbieten Verhaltensweisen, die niemals auftreten sollten. Bei Kompatibilitätstests werden jetzt SELinux-neverallow-Regeln auf allen Geräten erzwungen.

Die folgenden Richtlinien sollen Herstellern helfen, Fehler im Zusammenhang mit neverallow-Regeln bei der Anpassung zu vermeiden. Die hier verwendeten Regelnummern entsprechen Android 5.1 und können sich mit der 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-Funktion ermöglicht es, jeden Prozess zu ptrace, was eine große Kontrolle über andere Prozesse ermöglicht und nur für bestimmte Systemkomponenten gelten sollte, die in der Regel beschrieben sind. Die Notwendigkeit dieser Funktion weist häufig auf etwas hin, das nicht für nutzerorientierte Builds oder Funktionen gedacht ist, 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;
Mit dieser Regel soll die Ausführung beliebigen Codes auf dem System verhindert werden. Insbesondere wird damit sichergestellt, dass nur Code auf /system ausgeführt wird, was dank Mechanismen wie dem sicheren Start Sicherheitsgarantien ermöglicht. Wenn ein Problem mit dieser neverallow-Regel auftritt, besteht die beste Lösung oft darin, den fehlerhaften Code in die /system-Partition zu verschieben.

SEPolicy unter Android 8.0 und höher anpassen

Dieser Abschnitt enthält Richtlinien für die SELinux-Richtlinien von Anbietern 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-Richtlinien für Partitionen und Android-Versionen kompatibel bleiben, finden Sie unter Kompatibilität.

Platzierung der Richtlinie

Unter Android 7.0 und niedriger konnten Gerätehersteller BOARD_SEPOLICY_DIRS Richtlinien hinzufügen, einschließlich Richtlinien, die die AOSP-Richtlinie für verschiedene Gerätetypen ergänzen sollten. Unter Android 8.0 und höher wird eine Richtlinie, die BOARD_SEPOLICY_DIRS hinzugefügt wird, nur im Anbieterimage platziert.

Unter Android 8.0 und höher finden Sie die Richtlinie an den folgenden Stellen in AOSP:

  • system/sepolicy/public. Enthält Richtlinien, die zur Verwendung in anbieterspezifischen Richtlinien exportiert wurden. Alle Informationen werden in die Kompatibilitätsinfrastruktur von Android 8.0 aufgenommen. Die öffentlichen Richtlinien gelten für alle Releases. Du kannst also beliebige /public-Werte in deine benutzerdefinierte Richtlinie aufnehmen. Aus diesem Grund sind die Richtlinien, die in /public platziert werden können, stärker eingeschränkt. Das ist die exportierte Richtlinien-API der Plattform: Alles, was sich mit der Schnittstelle zwischen /system und /vendor befasst, gehört hierher.
  • system/sepolicy/private. Umfasst eine Richtlinie, die für das Funktionieren des System-Images erforderlich ist, von der aber keine Kenntnisse über die Anbieter-Image-Richtlinie haben sollte.
  • system/sepolicy/vendor. Enthält Richtlinien für Komponenten, die in /vendor abgelegt werden, aber im Stammverzeichnis der Hauptplattform vorhanden sind (nicht in gerätespezifischen Verzeichnissen). Dies ist ein Artefakt der Unterscheidung zwischen Geräten und globalen Komponenten im Build-System. Konzeptionell ist dies Teil der unten beschriebenen gerätespezifischen Richtlinie.
  • device/manufacturer/device-name/sepolicy. Enthält gerätespezifische Richtlinie. Umfasst auch Geräteanpassungen an die Richtlinie, die bei Android 8.0 und höher der Richtlinie für Komponenten im Anbieter-Image entspricht.

Unter Android 11 und höher können die Partitionen „system_ext“ und „product“ auch partitionspezifische Richtlinien enthalten. Die Richtlinien für „system_ext“ und „product“ sind ebenfalls in öffentliche und private Richtlinien unterteilt. Anbieter können die öffentlichen Richtlinien für „system_ext“ und „product“ wie die Systemrichtlinie verwenden.

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. Enthält Richtlinie, die zur Verwendung in einer anbieterspezifischen Richtlinie exportiert wurde. Installiert auf der Partition „system_ext“.
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. Enthält Richtlinien, die für die Funktion des system_ext-Images erforderlich sind, von denen die Anbieter-Image-Richtlinie jedoch keine Kenntnis haben sollte. Installiert auf der Partition „system_ext“.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS. Enthält eine Richtlinie, die zur Verwendung in einer anbieterspezifischen Richtlinie exportiert wurde. Auf der Produktpartition installiert.
  • PRODUCT_PRIVATE_SEPOLICY_DIRS. Enthält Richtlinien, die für die Funktion des Produktbilds erforderlich sind, von denen die Richtlinien für das Bild des Anbieters jedoch keine Kenntnis haben sollten. Auf der Produktpartition installiert.
Hinweis:Bei Verwendung von GSI werden die system_ext- und Produktpartitionen des OEM nicht bereitgestellt. Die Regeln in der Sepolicy des Anbieters, die die system_ext- und die öffentliche Produktrichtlinie des OEMs verwenden, werden zu NOPs, 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 müssen Kompatibilitätsprobleme selbst beheben.

Unterstützte Richtlinienszenarien

Auf Geräten, die mit Android 8.0 oder höher ausgeliefert werden, muss das Anbieter-Image mit dem OEM-System-Image und dem von Google bereitgestellten Referenz-AOSP-System-Image funktionieren und das CTS für dieses Referenz-Image bestehen. Diese Anforderungen sorgen für eine klare Trennung zwischen dem Framework und dem Anbietercode. Auf solchen Geräten sind die folgenden Szenarien möglich.

Erweiterungen vom Typ „Nur Anbieterbild“

Beispiel:Ein neuer Dienst wird zu vndservicemanager aus dem Anbieter-Image hinzugefügt, das Prozesse aus dem Anbieter-Image unterstützt.

Fügen Sie wie bei Geräten, die mit früheren Android-Versionen auf den Markt gebracht werden, gerätespezifische Anpassungen unter device/manufacturer/device-name/sepolicy hinzu. Die neue Richtlinie, die die Interaktion von Anbieterkomponenten (nur) mit anderen Anbieterkomponenten regelt, sollte Typen umfassen, die nur in device/manufacturer/device-name/sepolicy vorhanden sind. Die hier beschriebene Richtlinie ermöglicht die Ausführung von Code des Anbieters, wird nicht im Rahmen einer OTA-Aktualisierung nur für das Framework aktualisiert und ist in der kombinierten Richtlinie auf einem Gerät mit dem Referenz-AOSP-System-Image enthalten.

Anbieter-Image-Unterstützung für die Zusammenarbeit mit AOSP

Beispiel:Hinzufügen eines neuen Prozesses (im Anbieter-Image mit hwservicemanager registriert), der eine von AOSP definierte HAL implementiert.

Wie bei Geräten, die mit früheren Android-Versionen auf den Markt gebracht werden, können Sie die gerätespezifischen Anpassungen in device/manufacturer/device-name/sepolicy vornehmen. Die im Rahmen von system/sepolicy/public/ exportierte Richtlinie kann verwendet werden und ist Teil der Anbieterrichtlinie. Typen und Attribute aus der öffentlichen Richtlinie können in neuen Regeln verwendet werden, die Interaktionen mit den neuen anbieterspezifischen Bits regeln, vorbehaltlich der angegebenen neverallowEinschränkungen. Wie bei der anbieterspezifischen Version wird die neue Richtlinie hier nicht im Rahmen eines OTA-Updates für das Framework aktualisiert. Sie ist in der kombinierten Richtlinie auf einem Gerät mit dem Referenz-AOSP-System-Image vorhanden.

Erweiterungen nur mit System-Image

Beispiel:Hinzufügen eines neuen Dienstes (beim Dienstmanager registriert), auf den nur andere Prozesse aus dem System-Image 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 aktivieren, vorausgesetzt, dass diese neuen Bits nicht mit neuen Komponenten im Anbieter-Image interagieren müssen (insbesondere müssen diese Prozesse oder Objekte ohne Richtlinie aus dem Anbieter-Image vollständig funktionieren). Die von system/sepolicy/public exportierte Richtlinie ist hier ebenso verfügbar wie für Erweiterungen, die nur Bilder von Anbietern enthalten. Diese Richtlinie ist Teil des System-Images und kann über eine reine OTA-Aktualisierung des Frameworks aktualisiert werden. Sie ist jedoch nicht vorhanden, wenn das Referenz-AOSP-System-Image verwendet wird.

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

Beispiel:Eine neue, nicht AOSP-HAL für die Verwendung durch erweiterte Clients, die auch im AOSP-System-Image 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. Das ist ähnlich wie beim obigen Szenario, bei dem die Unterstützung von Anbieter-Images für die Verwendung mit dem Referenz-AOSP-Image hinzugefügt wird. Mit der Ausnahme, dass für die geänderten AOSP-Komponenten möglicherweise auch zusätzliche Richtlinien erforderlich sind, damit sie ordnungsgemäß mit dem Rest der Systempartition funktionieren. Das ist in Ordnung, solange sie weiterhin die öffentlichen AOSP-Typlabels haben.

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

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

Beispiel:Ein neuer Systemprozess, der nicht zu AOSP gehört, muss auf eine HAL zugreifen, auf die AOSP angewiesen ist.

Dies ähnelt dem Beispiel für die Erweiterung „Nur System-Image“, mit dem Unterschied, dass neue Systemkomponenten über die system/vendor-Schnittstelle interagieren können. Die Richtlinie für die neue Systemkomponente muss in system/sepolicy/private abgelegt werden. Das ist zulässig, sofern sie über eine von AOSP in system/sepolicy/public bereits eingerichtete Schnittstelle erfolgt, d. h., die für die Funktionalität erforderlichen Typen und Attribute sind vorhanden. Die Richtlinie kann zwar in die gerätespezifische Richtlinie aufgenommen werden, aber es können keine anderen system/sepolicy/private-Typen verwendet werden und sie kann sich aufgrund eines reinen Framework-Updates nicht auf eine Weise ändern, die sich auf die Richtlinie auswirkt. Die Richtlinie kann in einer OTA-Aktualisierung nur für das Framework geändert werden, ist aber bei Verwendung eines AOSP-System-Images nicht vorhanden (das auch die neue Systemkomponente nicht enthält).

Anbieterbilderweiterungen, die für neue Systemkomponenten ausgeliefert werden

Beispiel:Hinzufügen einer neuen nicht AOSP-HAL für die Verwendung durch einen Clientprozess ohne AOSP-Analogon (erfordert daher eine eigene Domain).

Ähnlich wie im Beispiel für AOSP-Erweiterungen muss die Richtlinie für Interaktionen zwischen System und Anbieter im Verzeichnis device/manufacturer/device-name/sepolicy abgelegt werden, das in der Anbieterpartition enthalten ist. So wird sichergestellt, dass die Systemrichtlinie keine anbieterspezifischen Details kennt. Sie können neue öffentliche Typen hinzufügen, die die Richtlinie in system/sepolicy/public erweitern. Dies sollte nur zusätzlich zur vorhandenen AOSP-Richtlinie erfolgen, d. h., die öffentliche AOSP-Richtlinie darf nicht entfernt werden. Die neuen öffentlichen Typen können dann für Richtlinien in system/sepolicy/private und device/manufacturer/device-name/sepolicy verwendet werden.

Jede Ergänzung zu system/sepolicy/public erhöht die Komplexität, da eine neue Kompatibilitätsgarantie erforderlich ist, die in einer Zuordnungsdatei erfasst werden muss und anderen Einschränkungen unterliegt. In system/sepolicy/public können nur neue Typen und entsprechende Zulassungsregeln hinzugefügt werden. Attribute und andere Richtlinienaussagen werden nicht unterstützt. Außerdem können neue öffentliche Typen nicht verwendet werden, um Objekte in der Richtlinie /vendor direkt zu labeln.

Nicht unterstützte Richtlinienszenarien

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

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

Beispiel:In der nächsten Android-Version wird ein neuer nicht AOSP-Systemprozess hinzugefügt, der eine eigene Domain benötigt und Zugriff auf eine neue nicht AOSP-HAL benötigt.

Ähnlich wie bei der Interaktion von neuen (nicht AOSP-)System- und Anbieterkomponenten, mit der Ausnahme, dass der neue Systemtyp in einem OTA-Update nur für das Framework eingeführt wird. Der neue Typ kann der Richtlinie in system/sepolicy/public zwar hinzugefügt werden, aber die vorhandene Anbieterrichtlinie kennt den neuen Typ nicht, da nur die öffentliche Richtlinie für das Android 8.0-System erfasst wird. AOSP löst dieses Problem, indem von Anbietern bereitgestellte Ressourcen über ein Attribut (z. B. das hal_foo-Attribut) freigegeben werden. Da Attributerweiterungen für Partner in system/sepolicy/public jedoch nicht unterstützt werden, ist diese Methode für Anbieterrichtlinien nicht verfügbar. Der Zugriff muss über einen bereits vorhandenen öffentlichen Typ erfolgen.

Beispiel:Eine Änderung an einem Systemprozess (AOSP oder nicht AOSP) muss sich auf die Interaktion mit einer neuen, nicht AOSP-spezifischen Anbieterkomponente auswirken.

Die Richtlinie für das System-Image muss ohne Kenntnis bestimmter Anbieteranpassungen geschrieben werden. Richtlinien für bestimmte Schnittstellen in AOSP werden daher über Attribute in system/sepolicy/public freigegeben, damit die Anbieterrichtlinien zukünftige Systemrichtlinien aktivieren können, die diese Attribute verwenden. Attributerweiterungen in system/sepolicy/public werden jedoch nicht unterstützt. Daher müssen alle Richtlinien, die festlegen, wie die Systemkomponenten mit neuen Anbieterkomponenten interagieren (und die nicht durch Attribute verwaltet werden, die bereits in AOSP system/sepolicy/public vorhanden sind), in device/manufacturer/device-name/sepolicy enthalten sein. Das bedeutet, dass Systemtypen den Zugriff für Anbietertypen im Rahmen einer OTA-Aktualisierung, die nur das Framework betrifft, nicht ändern können.