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 standardmäßigen SELinux-Einstellungen nicht entfernen.

Hersteller sollten bestehende SELinux-Richtlinien nicht entfernen. Andernfalls riskieren sie, die Android SELinux-Implementierung und die von ihr gesteuerten Anwendungen zu beschädigen. Dazu gehören Anwendungen von Drittanbietern, die wahrscheinlich verbessert werden müssen, um konform und betriebsbereit zu sein. Anwendungen dürfen keine Änderung erfordern, um weiterhin auf SELinux-fähigen Geräten zu funktionieren.

Denken Sie beim Anpassen von SELinux an Folgendes:

• Schreiben Sie die SELinux-Richtlinie für alle neuen Daemons
• Verwenden Sie bei Bedarf vordefinierte Domänen
• Weisen Sie jedem als init -Dienst erzeugten Prozess 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, nicht:

• Erstellen Sie eine inkompatible Richtlinie
• Anpassung der Endbenutzerrichtlinie zulassen
• MDM-Richtlinienanpassungen zulassen
• 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 der gesamte Zugriff explizit in der Richtlinie zugelassen 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 darauf, vorhandene Anwendungen nicht zu beschädigen. Um loszulegen:

1. Verwenden Sie den neuesten Android-Kernel .
2. Wenden Sie das Prinzip der geringsten Privilegien an .
3. Adressieren Sie nur Ihre eigenen Ergänzungen zu Android. Die Standardrichtlinie funktioniert automatisch mit der Codebasis des Android Open Source-Projekts .
4. Teilen Sie Softwarekomponenten in Module auf, 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 BOARD_SEPOLICY -Variablen, um sie in Ihren Build aufzunehmen.
7. Machen Sie neue Domains zunächst permissiv. Dies geschieht durch eine zulässige 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 keine weiteren Denials in Userdebug-Builds erscheinen.

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

Wenn Sie mit der Anpassung von SELinux beginnen, prü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 zugehörigen Richtlinien des OEM erfüllt, bevor Sie den Erzwingungsmodus aktivieren.

Um unnötige Probleme zu vermeiden, ist es besser, zu breit und überkompatibel zu sein, als zu restriktiv und inkompatibel, was zu fehlerhaften Gerätefunktionen führt. Umgekehrt, wenn Ihre Änderungen anderen zugute kommen, sollten Sie die Änderungen an der standardmäßigen 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.

Beispiele für Richtlinienanweisungen

SELinux basiert auf der M4 -Computersprache 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 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 };

Analysieren wir das Beispiel:

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

In der zweiten Zeile wird DHCP als permissive Domain gekennzeichnet.

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

In der net_domain(dhcp) erlaubt die Richtlinie DHCP die Nutzung allgemeiner Netzwerkfunktionen aus der net Domäne wie das Lesen und Schreiben von TCP-Paketen, die Kommunikation über Sockets und das Durchführen von DNS-Anforderungen.

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

Der letzte Block des Beispiels beginnt mit allow dhcp netd:fd use; zeigt, 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 können. DHCP darf die Datagramm-Sockets und UNIX-Stream-Sockets nur lesen und schreiben und sie nicht erstellen oder öffnen.

Verfügbare Steuerelemente

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

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

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

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

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

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

Neverallow-Regeln

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

Die folgenden Richtlinien sollen Herstellern dabei helfen, Fehler im Zusammenhang mit neverallow Regeln während der Anpassung zu vermeiden. Die hier verwendeten Regelnummern entsprechen Android 5.1 und können sich bis zur 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, die in der Regel umrissen sind. Die Notwendigkeit dieser Funktion weist häufig auf das Vorhandensein von etwas hin, das nicht für benutzerorientierte Builds oder nicht benötigte Funktionen vorgesehen ist. 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 von beliebigem Code auf dem System verhindern. Insbesondere wird behauptet, dass nur Code auf /system ausgeführt wird, was Sicherheitsgarantien dank Mechanismen wie verifiziertem Booten ermöglicht. Oft ist die beste Lösung, wenn ein Problem mit dieser neverallow Regel auftritt, den störenden Code auf die /system Partition zu verschieben.

Anpassen von SEPolicy in Android 8.0+

Dieser Abschnitt enthält Richtlinien für die SELinux-Richtlinie 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 darüber, 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 Richtlinien zur Erweiterung der AOSP-Richtlinie für verschiedene Gerätetypen. In Android 8.0 und höher platziert das Hinzufügen einer Richtlinie zu BOARD_SEPOLICY_DIRS die Richtlinie nur im Anbieter-Image.

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

• system/sepolicy/public . Enthält eine Richtlinie, die zur Verwendung in einer herstellerspezifischen Richtlinie exportiert wurde. Alles fließt in die Android 8.0- Kompatibilitätsinfrastruktur ein . Die öffentliche Richtlinie soll über Versionen hinweg bestehen bleiben, sodass Sie alles /public in Ihre benutzerdefinierte Richtlinie aufnehmen können. Aus diesem Grund ist die Art der Richtlinie, die in /public platziert werden kann, eingeschränkter. Betrachten Sie dies als die exportierte Richtlinien-API der Plattform: Alles, was mit der Schnittstelle zwischen /system und /vendor zu tun hat, gehört hierher.
• system/sepolicy/privat . Beinhaltet eine Richtlinie, die für das Funktionieren des Systemabbilds erforderlich ist, von der die Abbildrichtlinie des Anbieters jedoch keine Kenntnis haben sollte.
• system/sepolicy/anbieter . Schließt Richtlinie für Komponenten ein, die in /vendor gehen, aber in der Kernplattformstruktur vorhanden sind (nicht gerätespezifische Verzeichnisse). Dies ist ein Artefakt der Unterscheidung des Build-Systems zwischen Geräten und globalen Komponenten; konzeptionell ist dies ein Teil der unten beschriebenen gerätespezifischen Richtlinie.
• Gerät/ manufacturer / device-name / sepolicy . Enthält eine gerätespezifische Richtlinie. Schließt auch Geräteanpassungen in die Richtlinie ein, die in Android 8.0 und höher der Richtlinie für Komponenten auf dem 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 product wie die Systemrichtlinie verwenden.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Enthält eine Richtlinie, die zur Verwendung in einer herstellerspezifischen Richtlinie exportiert wurde. Auf system_ext-Partition installiert.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Enthält eine Richtlinie, die für das Funktionieren des system_ext-Images erforderlich ist, von der die Hersteller-Image-Richtlinie jedoch keine Kenntnis haben sollte. Auf system_ext-Partition installiert.
• PRODUCT_PUBLIC_SEPOLICY_DIRS . Enthält eine Richtlinie, die zur Verwendung in einer herstellerspezifischen Richtlinie exportiert wurde. Auf der Produktpartition installiert.
• PRODUCT_PRIVATE_SEPOLICY_DIRS . Beinhaltet eine Richtlinie, die für das Funktionieren des Produktbildes erforderlich ist, von der die Bildrichtlinie des Anbieters 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 Hersteller-Image mit dem OEM-System-Image und dem von Google bereitgestellten Referenz-AOSP-System-Image funktionieren (und CTS an 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-Vendor-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 . Die neue Richtlinie, die regelt, wie Anbieterkomponenten mit (nur) anderen Anbieterkomponenten interagieren, sollte Typen beinhalten, die nur in device/ manufacturer / device-name /sepolicy . Die hier geschriebene Richtlinie lässt zu, dass Code beim Anbieter funktioniert, wird nicht als Teil eines reinen Framework-OTA aktualisiert und ist in der kombinierten Richtlinie auf einem Gerät mit dem Referenz-AOSP-Systemabbild vorhanden.

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

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

Führen Sie wie bei Geräten, die mit früheren Android-Versionen gestartet werden, eine gerätespezifische Anpassung in device/ manufacturer / device-name /sepolicy . Die als Teil von system/sepolicy/public/ exportierte Richtlinie steht zur Verwendung zur Verfügung und wird als Teil der Herstellerrichtlinie geliefert. Typen und Attribute aus der öffentlichen Richtlinie können in neuen Regeln verwendet werden, die Interaktionen mit den neuen anbieterspezifischen Bits vorschreiben, vorbehaltlich der bereitgestellten neverallow Einschränkungen. Wie im reinen Anbieterfall 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-Systemabbild 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 . Sie können zusätzliche Prozesse oder Objekte hinzufügen, um die Funktionalität in einem Partnersystem-Image zu aktivieren, vorausgesetzt, diese neuen Bits müssen nicht mit neuen Komponenten auf dem Anbieter-Image interagieren (insbesondere müssen solche 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 Nur-Anbieter-Image-Erweiterungen. Diese Richtlinie ist Teil des Systemabbilds und könnte in einem Nur-Framework-OTA aktualisiert werden, ist jedoch nicht vorhanden, wenn das Referenz-AOSP-Systemabbild verwendet wird.

Vendor-Image-Erweiterungen, die erweiterte AOSP-Komponenten bedienen

Beispiel: Eine neue 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 ausgeliefert wird. Dies ähnelt dem obigen Szenario des Hinzufügens von Anbieter-Image-Unterstützung, um mit dem Referenz-AOSP-Image zu arbeiten, außer dass die modifizierten 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 die öffentlichen AOSP-Typenschilder haben).

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

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 Erweiterungsbeispiel nur für das System-Image , mit der Ausnahme, dass neue Systemkomponenten über die system/vendor -Schnittstelle interagieren können. Die Richtlinie für die neue Systemkomponente muss in system/sepolicy/private gehen, was akzeptabel ist, vorausgesetzt, es erfolgt über eine Schnittstelle, die bereits von AOSP in system/sepolicy/public eingerichtet wurde (dh die für die Funktionalität erforderlichen Typen und Attribute sind dort vorhanden). Während die Richtlinie in der gerätespezifischen Richtlinie enthalten sein könnte, wäre sie nicht in der Lage, andere system/sepolicy/private Typen zu verwenden oder sich (auf irgendeine richtlinienbeeinflussende Weise) als Ergebnis einer Nur-Framework-Aktualisierung zu ändern. Die Richtlinie kann in einem reinen Framework-OTA geändert werden, ist aber nicht vorhanden, wenn ein AOSP-Systemabbild verwendet wird (das auch nicht über die neue Systemkomponente verfügt).

Anbieter-Image-Erweiterungen, die neue Systemkomponenten bedienen

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

Ä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 werden, das auf der Anbieterpartition ausgeliefert wird (um sicherzustellen, dass die Systemrichtlinie keine Kenntnis von anbieterspezifischen Details hat). Sie können neue öffentliche Typen hinzufügen, die die Richtlinie in system/sepolicy/public ; dies sollte nur zusätzlich zur bestehenden AOSP-Richtlinie erfolgen, dh die öffentliche AOSP-Richtlinie nicht entfernen. Die neuen öffentlichen Typen können dann für Richtlinien in system/sepolicy/private und in device/ manufacturer / device-name /sepolicy .

Denken Sie daran, 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. Nur neue Typen und entsprechende Zulassungsregeln können in system/sepolicy/public hinzugefügt werden; Attribute und andere Richtlinienanweisungen werden nicht unterstützt. Außerdem 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 Nur-Framework-OTA eine Genehmigung 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 , außer dass der neue Systemtyp in einem reinen Framework-OTA eingeführt wird. Obwohl der neue Typ der Richtlinie in system/sepolicy/public hinzugefügt werden könnte, hat die vorhandene Anbieterrichtlinie keine Kenntnis des neuen Typs, da sie nur die öffentliche Richtlinie des Android 8.0-Systems verfolgt. AOSP handhabt dies, indem vom Anbieter bereitgestellte Ressourcen über ein Attribut (z. B. hal_foo -Attribut) verfügbar gemacht werden. Da jedoch Attributpartnererweiterungen in system/sepolicy/public nicht unterstützt werden, ist diese Methode für die Anbieterrichtlinie nicht verfügbar. Der Zugriff muss von einem zuvor vorhandenen öffentlichen Typ bereitgestellt werden.

Beispiel: Eine Änderung an einem Systemprozess (AOSP oder Nicht-AOSP) muss ändern, wie er mit einer neuen Nicht-AOSP-Anbieterkomponente interagiert.

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