Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

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 für SELinux nicht entfernen.

Hersteller sollten bestehende SELinux-Richtlinien nicht entfernen. Andernfalls besteht die Gefahr, dass die Android SELinux-Implementierung und die von ihr gesteuerten Anwendungen beschädigt werden. Dies schließt Anwendungen von Drittanbietern ein, die wahrscheinlich verbessert werden müssen, um konform und betriebsbereit zu sein. Anwendungen müssen nicht geändert werden, um auf SELinux-fähigen Geräten weiter zu funktionieren.

Beachten Sie beim Anpassen von SELinux Folgendes:

  • Schreiben Sie eine SELinux-Richtlinie für alle neuen Daemons
  • Verwenden Sie gegebenenfalls vordefinierte Domänen
  • Weisen Sie jedem Prozess, der als init Service 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, nicht:

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

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

SELinux verwendet einen Whitelist-Ansatz. Dies bedeutet, dass jeder Zugriff in Richtlinien ausdrücklich zugelassen werden muss, um gewährt zu werden. Da die Standard-SELinux-Richtlinie von Android das Android Open Source-Projekt 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. So fangen Sie an:

  1. Verwenden Sie den neuesten Android-Kernel .
  2. Übernehmen Sie das Prinzip des geringsten Privilegs .
  3. Adressieren Sie nur Ihre eigenen Ergänzungen zu Android. Die Standardrichtlinie funktioniert automatisch mit der Android Open Source Project- Codebasis.
  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. *.te Sie diese Richtlinien in *.te Dateien (die Erweiterung für SELinux-Richtlinienquelldateien) im Verzeichnis /device/ manufacturer / device-name /sepolicy und verwenden BOARD_SEPOLICY Variablen BOARD_SEPOLICY , um sie in Ihren Build aufzunehmen.
  7. Machen Sie neue Domains zunächst zulässig. Dies erfolgt mithilfe einer zulässigen Deklaration in der .te Datei der Domäne.
  8. Analysieren Sie die Ergebnisse und verfeinern Sie Ihre Domain-Definitionen.
  9. Entfernen Sie die zulässige Deklaration, wenn in Userdebug-Builds keine weiteren Ablehnungen angezeigt werden.

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

Wenn Sie mit dem Anpassen 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 den Sicherheitsrichtlinien von Android sowie den vom OEM erstellten zugehörigen Richtlinien entspricht, bevor Sie den Durchsetzungsmodus aktivieren.

Um unnötige Probleme zu vermeiden, ist es besser, überlastet und überkompatibel zu sein als zu restriktiv und inkompatibel, was zu Funktionsstörungen des Geräts führt. Umgekehrt sollten Sie die Änderungen als Patch an die Standard-SELinux-Richtlinie senden, wenn Ihre Änderungen anderen zugute kommen. 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 Domänen Zugriff zum Lesen oder Schreiben von /dev/null und zum Lesen von /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 };

*_file_perms Anweisung kann mit SELinux *_file_perms Makros (Kurzform) 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 };

Lassen Sie uns das Beispiel analysieren:

In der ersten Zeile, der Typdeklaration, erbt der DHCP-Dämon von der Basissicherheitsrichtlinie ( domain ). Aus den vorherigen Anweisungsbeispielen kann DHCP aus /dev/null lesen und in diese schreiben.

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

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

Im net_domain(dhcp) Linie, erlaubt die Richtlinie DHCP gemeinsame Netzwerkfunktionalität von dem verwenden net - Domain wie das Lesen und Schreiben von TCP - Paketen, die Kommunikation über Sockets und DNS - Anfragen durch.

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

Der letzte Block des Beispiels, der 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 nur in Datagramm-Sockets und UNIX-Stream-Sockets lesen und daraus schreiben und diese nicht erstellen oder öffnen.

Verfügbare Steuerelemente

Klasse Genehmigung
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
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
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

Regeln niemals zulassen

SELinux neverallow Regeln verbieten Verhalten , die niemals auftreten sollte. Mit Kompatibilitätstests werden SELinux neverallow Regeln jetzt neverallow durchgesetzt.

Die folgenden Richtlinien sollen Herstellern 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 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 Funktion sys_ptrace bietet die Möglichkeit, jeden Prozess zu ptrace ermöglicht eine umfassende Kontrolle über andere Prozesse und sollte nur zu den in der Regel beschriebenen Systemkomponenten gehören. Die Notwendigkeit dieser Funktion weist häufig auf das Vorhandensein von etwas hin, das nicht für benutzerbezogene 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;
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 dank Mechanismen wie verifiziertem Booten Sicherheitsgarantien ermöglicht. Häufig besteht die beste Lösung bei Problemen mit dieser neverallow Regel darin, den fehlerhaften Code auf die Partition /system .

Anpassen von SEPolicy in Android 8.0+

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

Platzierung von Richtlinien

In Android 7.0 und früheren BOARD_SEPOLICY_DIRS konnten BOARD_SEPOLICY_DIRS BOARD_SEPOLICY_DIRS Richtlinien BOARD_SEPOLICY_DIRS , einschließlich Richtlinien, mit denen die AOSP-Richtlinien für verschiedene Gerätetypen erweitert werden sollen. In Android 8.0 und höher wird durch Hinzufügen einer Richtlinie zu BOARD_SEPOLICY_DIRS die Richtlinie nur im Herstellerabbild platziert.

In Android 8.0 und höher gibt es Richtlinien an den folgenden Stellen in AOSP:

  • system / sepolicy / public . Enthält Richtlinien, die zur Verwendung in herstellerspezifischen Richtlinien exportiert wurden. Alles geht in die Android 8.0- Kompatibilitätsinfrastruktur . Öffentliche Richtlinien sollen über Releases hinweg bestehen bleiben, damit 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 sich mit der Schnittstelle zwischen /system und /vendor gehört hierher.
  • system / sepolicy / privat . Enthält Richtlinien, die für das Funktionieren des Systemabbilds erforderlich sind, von denen jedoch die Herstellerabbildrichtlinie keine Kenntnis haben sollte.
  • System / Politik / Anbieter . Enthält Richtlinien für Komponenten, die in /vendor aber in der Kernplattformstruktur vorhanden sind (keine gerätespezifischen 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 / Sicherheit . Enthält gerätespezifische Richtlinien. Enthält auch Geräteanpassungen an Richtlinien, die in Android 8.0 und höher der Richtlinie für Komponenten im Herstellerimage entsprechen.

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 für dieses Referenz-Image übergeben). Diese Anforderungen gewährleisten eine saubere Trennung zwischen dem Framework und dem Herstellercode. Solche Geräte unterstützen die folgenden Szenarien.

Nur-Hersteller-Image-Erweiterungen

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

device/ manufacturer / device-name /sepolicy wie bei Geräten, die mit früheren Android-Versionen gestartet wurden, gerätespezifische Anpassungen in device/ manufacturer / device-name /sepolicy . Neue Richtlinien, die regeln, wie Anbieterkomponenten mit (nur) anderen Anbieterkomponenten interagieren, sollten Typen umfassen, die nur in device/ manufacturer / device-name /sepolicy . Die hier geschriebene Richtlinie ermöglicht das Funktionieren des Codes des Anbieters, wird nicht als Teil eines Nur-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 beim hwservicemanager aus dem Vendor-Image), der eine AOSP-definierte HAL implementiert.

device/ manufacturer / device-name /sepolicy wie bei Geräten, die mit früheren Android-Versionen gestartet wurden, eine gerätespezifische Anpassung unter device/ manufacturer / device-name /sepolicy . Die als Teil von system/sepolicy/public/ exportierte system/sepolicy/public/ steht zur Verwendung zur Verfügung und wird als Teil der Lieferantenrichtlinie ausgeliefert. Typen und Attribute aus der öffentlichen Richtlinie können in neuen Regeln verwendet werden, die Interaktionen mit den neuen herstellerspezifischen Bits neverallow , vorbehaltlich der bereitgestellten, neverallow Einschränkungen. Wie im Fall nur für Anbieter wird die neue Richtlinie hier nicht als Teil eines Nur-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 beim 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 im Vendor-Image interagieren (insbesondere müssen solche Prozesse oder Objekte ohne Richtlinien aus dem Vendor-Image vollständig funktionieren). . Die von system/sepolicy/public exportierte system/sepolicy/public ist hier genauso verfügbar wie für Erweiterungen, die nur vom Hersteller bereitgestellt werden. Diese Richtlinie ist Teil des Systemabbilds und kann in einem Nur-Framework-OTA aktualisiert werden, ist jedoch bei Verwendung des Referenz-AOSP-Systemabbilds nicht vorhanden.

Hersteller-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 Systemserver).

Die Richtlinien für die Interaktion zwischen System und Hersteller müssen im Verzeichnis device/ manufacturer / device-name /sepolicy , das auf der Herstellerpartition ausgeliefert wird. Dies ähnelt dem obigen Szenario des Hinzufügens von Vendor-Image-Unterstützung für die Arbeit mit dem Referenz-AOSP-Image, außer dass für die geänderten AOSP-Komponenten möglicherweise zusätzliche Richtlinien erforderlich sind, um ordnungsgemäß mit dem Rest der Systempartition zu arbeiten (was in Ordnung ist, solange sie noch funktionieren haben die öffentlichen AOSP-Typbezeichnungen).

Die Richtlinie für die Interaktion öffentlicher AOSP-Komponenten mit Nur-System-Image-Erweiterungen sollte 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 sich AOSP stützt.

Dies ähnelt dem Beispiel für eine 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 ist akzeptabel, sofern sie über eine von AOSP bereits in system/sepolicy/public eingerichtete Schnittstelle system/sepolicy/public (dh die für die Funktionalität erforderlichen Typen und Attribute sind vorhanden). Die Richtlinie könnte zwar in die gerätespezifische Richtlinie aufgenommen werden, sie kann jedoch aufgrund eines Nur-Framework-Updates keine anderen system/sepolicy/private Typen verwenden oder Änderungen (auf system/sepolicy/private Weise) system/sepolicy/private . Die Richtlinie kann in einem Nur-Framework-OTA geändert werden, ist jedoch bei Verwendung eines AOSP-Systemabbilds (das auch keine neue Systemkomponente enthält) nicht vorhanden.

Vendor-Image-Erweiterungen, die neue Systemkomponenten bedienen

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

Ähnlich wie im Beispiel für AOSP-Erweiterungen muss sich die Richtlinie für Interaktionen zwischen System und Hersteller im Verzeichnis device/ manufacturer / device-name /sepolicy , das auf der Herstellerpartition ausgeliefert wird (um sicherzustellen, dass die device/ manufacturer / device-name /sepolicy keine Kenntnis herstellerspezifischer Details hat). Sie können neue öffentliche Typen hinzufügen, die die Richtlinie in system/sepolicy/public . Dies sollte nur zusätzlich zu der vorhandenen AOSP-Richtlinie erfolgen, dh nicht die öffentliche AOSP-Richtlinie entfernen. Die neuen öffentlichen Typen können dann für Richtlinien in system/sepolicy/private und in device/ manufacturer / device-name /sepolicy .

system/sepolicy/public Sie, dass jede Erweiterung von system/sepolicy/public die Komplexität system/sepolicy/public indem eine neue Kompatibilitätsgarantie system/sepolicy/public , die in einer Zuordnungsdatei nachverfolgt werden muss und anderen Einschränkungen unterliegt. In system/sepolicy/public dürfen nur neue Typen und entsprechende system/sepolicy/public hinzugefügt system/sepolicy/public . Attribute und andere Richtlinienanweisungen werden nicht unterstützt. Darüber hinaus können neue öffentliche Typen nicht zum direkten Beschriften von Objekten in der Richtlinie /vendor werden.

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 für das System-Image, die nach einem Nur-Framework-OTA die Berechtigung für neue Hersteller-Image-Komponenten benötigen

Beispiel: Ein neuer Nicht-AOSP-Systemprozess, für den eine eigene Domäne erforderlich ist, 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-) System- und Anbieterkomponenten , außer dass der neue Systemtyp in einem Nur-Framework-OTA eingeführt wird. Obwohl der neue Typ der Richtlinie in system/sepolicy/public hinzugefügt werden könnte, system/sepolicy/public die vorhandene Herstellerrichtlinie den neuen Typ nicht, da nur die öffentliche Richtlinie des Android 8.0-Systems verfolgt wird. AOSP behandelt dies, indem vom Anbieter bereitgestellte Ressourcen über ein Attribut (z. B. hal_foo Attribut hal_foo ) hal_foo werden. hal_foo jedoch Attributpartnererweiterungen in system/sepolicy/public nicht unterstützt system/sepolicy/public , ist diese Methode für Anbieterrichtlinien 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 Interaktion mit einer neuen Nicht-AOSP-Anbieterkomponente ändern.

Die Richtlinie auf dem Systemabbild muss ohne Kenntnis spezifischer Herstelleranpassungen geschrieben werden. Richtlinien zu bestimmten Schnittstellen in AOSP werden daher über Attribute in system / sepolicy / public verfügbar gemacht, sodass sich die Herstellerrichtlinie für zukünftige Systemrichtlinien entscheiden kann, die diese Attribute verwenden. Attributerweiterungen in system/sepolicy/public werden jedoch nicht unterstützt. system/sepolicy/public alle Richtlinien, die system/sepolicy/public , wie die Systemkomponenten mit neuen Anbieterkomponenten interagieren (und die nicht von Attributen behandelt werden, die bereits in AOSP system/sepolicy/public ), in device/ manufacturer / device-name /sepolicy . Dies bedeutet, dass Systemtypen den Zugriff auf Anbietertypen als Teil eines Nur-Framework-OTA nicht ändern können.