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:
- Verwenden Sie den neuesten Android-Kernel .
- Übernehmen Sie das Prinzip der geringsten Privilegien .
- Adressieren Sie nur Ihre eigenen Ergänzungen zu Android. Die Standardrichtlinie funktioniert automatisch mit der Codebasis des Android Open Source Project .
- Unterteilen Sie Softwarekomponenten in Module, die einzelne Aufgaben ausführen.
- Erstellen Sie SELinux-Richtlinien, die diese Aufgaben von nicht verwandten Funktionen isolieren.
- Legen Sie diese Richtlinien in
*.te
Dateien (die Erweiterung für SELinux-Richtlinienquelldateien) im Verzeichnis/device/ manufacturer / device-name /sepolicy
und verwenden SieBOARD_SEPOLICY
-Variablen, um sie in Ihren Build einzubinden. - Machen Sie neue Domains zunächst freizügig. Dies erfolgt durch die Verwendung einer permissiven Deklaration in der
.te
Datei der Domain. - Analysieren Sie die Ergebnisse und verfeinern Sie Ihre Domänendefinitionen.
- 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.
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.