SELinux anpassen

Nachdem Sie die Basisebene der SELinux-Funktionalität Ergebnisse gründlich analysiert haben, können Sie eigene Richtlinieneinstellungen hinzufügen, Ihre Anpassungen am Android-Betriebssystem. Diese Richtlinien müssen dennoch Sie müssen das Android-Kompatibilitätsprogramm erfüllen. Anforderungen und darf die SELinux-Standardeinstellungen nicht entfernen.

Hersteller dürfen bestehende SELinux-Richtlinien nicht entfernen. Andernfalls werden sie die Android SELinux-Implementierung und die Anwendungen, regelt. Dazu gehören auch Anwendungen von Drittanbietern, die wahrscheinlich Compliance und operativer Betrieb verbessert. Anwendungen dürfen keine um auf SELinux-fähigen Geräten weiterhin zu funktionieren.

Denken Sie beim Anpassen von SELinux an 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
• Machen Sie sich mit den Makros vertraut, bevor Sie eine Richtlinie schreiben.
• Änderungen an der Hauptrichtlinie an AOSP senden

Und nicht vergessen:

• Inkompatible Richtlinie erstellen
• Anpassung von Endnutzerrichtlinien zulassen
• Anpassungen der Richtlinien für die Mobilgeräteverwaltung zulassen
• Nutzer mit Richtlinienverstößen verängstigen
• Backdoors hinzufügen

Weitere Informationen finden Sie im Abschnitt Kernel-Sicherheitsfunktionen der Android Dokument zur Kompatibilitätsdefinition für spezifische Anforderungen.

SELinux verwendet einen Whitelist-Ansatz, d. h. jeglichen Zugriff muss ausdrücklich die gemäß der Richtlinie zulässig sind. Da das standardmäßige SELinux von Android -Richtlinie bereits das Android Open Source Project unterstützt, sind Sie nicht erforderlich SELinux-Einstellungen irgendwie zu ändern. Wenn Sie die SELinux-Einstellungen anpassen, darauf achten, vorhandene Anwendungen nicht zu zerstören. So gehts:

1. Verwenden Sie die Methode neueste Android-Version Kernel
2. Die Prinzip der geringsten Berechtigung.
3. Reagieren Sie nur auf Ihre eigenen Ergänzungen zu Android. Die Standardrichtlinie funktioniert mit das Open-Source-Tool von Android Projekt-Codebasis automatisch erstellt.
4. Softwarekomponenten in Module aufteilen, die einzelne Aufgaben.
5. Erstellen Sie SELinux-Richtlinien, um diese Aufgaben von nicht zusammenhängenden Aufgaben zu isolieren. Funktionen.
6. Lege diese Richtlinien in *.te-Dateien ab (die Erweiterung für SELinux). Richtlinienquelldateien) im /device/manufacturer/device-name/sepolicy und verwenden Sie BOARD_SEPOLICY-Variablen, um sie in Ihren Build.
7. Legen Sie für neue Domains zuerst einige Berechtigungen fest. Hierzu wird ein moderates Deklaration in der Datei .te der Domain ein.
8. Analysieren Sie die Ergebnisse und verfeinern Sie Ihre Domaindefinitionen.
9. Entfernen Sie die moderate Deklaration, wenn in „userdebug“ keine weiteren Ablehnungen angezeigt werden. baut.

Nachdem Sie die SELinux-Richtlinienänderung integriert haben, fügen Sie einen Schritt zu Ihrem zur Sicherstellung der SELinux-Kompatibilität. In einer idealen Softwareentwicklungsprozess kann die SELinux-Richtlinie nur geändert werden, wenn die Software und nicht die tatsächliche Implementierung.

Wenn Sie mit der Anpassung von SELinux beginnen, sollten Sie zuerst Ihre Ergänzungen zu Android überprüfen. Wenn Sie eine Komponente hinzugefügt haben, die eine neue Funktion ausführt, die Sicherheitsrichtlinien von Android sowie alle zugehörigen Richtlinien des bevor Sie den erzwungenen Modus aktivieren.

Um unnötige Probleme zu vermeiden, zu stark einschränkend und nicht kompatibel, was zu fehlerhaften Gerätefunktionen. Umgekehrt sollten Sie, wenn Ihre Änderungen anderen zugutekommen, die Änderungen an der SELinux-Standardrichtlinie als patch verwenden. Wenn der Patch auf die Standardsicherheitsrichtlinie angewendet wird, müssen Sie diese Änderung für jede neue Android-Version.

Beispiele für Richtlinienanweisungen

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

Im folgenden Beispiel wird allen Domains Lese- oder Lesezugriff gewährt. in /dev/null schreiben und aus /dev/zero lesen.

# 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 geschrieben werden. Makros (Kurzschreibweise):

# 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 weiter 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 Basissicherheitsrichtlinie (domain) Aus der vorherigen Anweisung 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) steht, dass DHCP von init erzeugt und darf mit diesem kommunizieren.

In der Zeile net_domain(dhcp) lässt die Richtlinie die Verwendung von DHCP zu gängige Netzwerkfunktionalität aus der Domain net, z. B. das Lesen von TCP-Pakete schreiben, über Sockets kommunizieren, -Anfragen.

In Zeile allow dhcp proc_net:file write; besagt die Richtlinie, DHCP kann in bestimmte Dateien in /proc schreiben. Diese Linie zeigt, Die fein abgestufte Dateibeschriftung von SELinux. Sie verwendet das Label proc_net. um den Schreibzugriff auf Dateien unter /proc/sys/net zu beschränken.

Der letzte Block des Beispiels beginnt mit allow dhcp netd:fd use; zeigt, wie Apps möglicherweise Folgendes tun dürfen: miteinander interagieren. Die Richtlinie besagt, dass DHCP und netd mit sich gegenseitig über Dateideskriptoren, FIFO-Dateien, Datagram-Sockets und einen UNIX-Stream Sockets. DHCP darf nur Daten in die Datagramm-Sockets und unter UNIX lesen und schreiben. und nicht erstellen oder öffnen.

Verfügbare Einstellungen

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

Niezulassen-Regeln

neverallow-Regeln von SELinux untersagen ein Verhalten, das niemals eintreten sollte. Bei Kompatibilitätstests neverallow-Regeln von SELinux werden jetzt geräteübergreifend erzwungen.

Die folgenden Richtlinien sollen Hersteller dabei unterstützen, Fehler zu vermeiden zu neverallow Regeln während der Anpassung. Die Regelnummern die hier verwendet wurden, entsprechen Android 5.1 und können sich je nach Release ändern.

Regel 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Siehe Manpage für ptrace. Das sys_ptrace die Fähigkeit, jeden beliebigen Prozess zu ptrace, was sehr viel Kontrolle über andere Prozesse und sollte nur zu einem dafür vorgesehenen System gehören. der in der Regel beschriebenen Komponenten. Die Notwendigkeit dieser Fähigkeit deutet oft darauf hin, das Vorhandensein von etwas, das nicht für nutzerseitige Builds bestimmt ist, 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 von beliebigem Code auf dem System verhindern. Insbesondere wird bestätigt, dass nur Code auf /system ausgeführt wird, das dank Mechanismen wie dem verifizierten Bootmodus Sicherheitsgarantien bietet. Oft ist die beste Lösung für dieses Problem neverallow ist es, den problematischen Code in die Partition /system.

SEPolicy unter Android 8.0 und höher anpassen

Dieser Abschnitt enthält Richtlinien für die SELinux-Richtlinien des Anbieters in Android 8.0 und einschließlich Details zur SEPolicy des Android Open Source Project (AOSP) und SEPolicy-Erweiterungen Weitere Informationen über die Beibehaltung der SELinux-Richtlinie Partitions- und Android-Versionen kompatibel, siehe Kompatibilität.

Richtlinienplatzierung

Unter Android 7.0 und niedriger konnten Gerätehersteller BOARD_SEPOLICY_DIRS, einschließlich Richtlinie zur Erweiterung der AOSP-Richtlinie auf verschiedenen Gerätetypen. Unter Android 8.0 und höher wird das Hinzufügen einer Richtlinie zu BOARD_SEPOLICY_DIRS fügt die Richtlinie nur für den Anbieter ein. Bild.

Ab Android 8.0 gibt es die Richtlinien an folgenden Stellen in AOSP:

• system/sepolicy/public Umfasst Richtlinie, die zur Nutzung exportiert wurden in der anbieterspezifischen Richtlinie. Alles läuft mit Android 8.0 Kompatibilitätsinfrastruktur. Die öffentlichen Richtlinien bleiben für alle Releases bestehen, sodass du /public in Ihrer benutzerdefinierten Richtlinie. Aus diesem Grund kann der Richtlinientyp in /public eingeschränkt. Dies ist die exportierte Richtlinien-API der Plattform: behandelt die Schnittstelle zwischen /system und /vendor gehört hier.
• system/sepolicy/private Enthält Richtlinien, die erforderlich sind für die Funktionsweise des System-Images ist, aber welche Anbieter-Image-Richtlinie keine Kenntnisse haben.
• system/sepolicy/vendor Umfasst Richtlinien für Komponenten, die gehen in /vendor, sind aber im zentralen Plattformbaum vorhanden (nicht gerätespezifische Verzeichnisse). Dies ist ein Artefakt des Build-Systems Unterscheidung zwischen Geräten und globalen Komponenten konzeptionell ist dies der unten beschriebenen gerätespezifischen Richtlinie.
• device/manufacturer/device-name/sepolicy Umfasst gerätespezifische Richtlinien. Dazu zählen auch Geräteanpassungen für , die unter Android 8.0 und höher der Richtlinie für Komponenten entspricht. auf das Anbieterbild.

Ab Android 11 können system_ext und Produktpartitionen auch Folgendes enthalten: partitionsspezifische Richtlinien zu erstellen. „system_ext“ und „product_policy“ sind ebenfalls in öffentlich und privat. Außerdem können Anbieter die öffentlichen wie die Systemrichtlinien.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS Umfasst Richtlinie, die exportiert wurde für die in einer anbieterspezifischen Richtlinie verwendet werden. Auf der Partition „system_ext“ installiert.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS Erforderliche Richtlinien für die Funktion des Images „system_ext“, aber von welchem Anbieter-Image sollte keine Kenntnis davon haben. Auf der Partition „system_ext“ installiert.
• PRODUCT_PUBLIC_SEPOLICY_DIRS Umfasst Richtlinie, die exportiert wurde für die in einer anbieterspezifischen Richtlinie verwendet werden. In der Produktpartition installiert.
• PRODUCT_PRIVATE_SEPOLICY_DIRS Enthält Richtlinien, die erforderlich sind für die Funktionsweise des Produkt-Images, aber von welcher Richtlinie für Anbieter-Images keine Kenntnisse haben. In der Produktpartition installiert.

Unterstützte Richtlinienszenarien

Auf Geräten mit Android 8.0 und höher muss das Anbieter-Image funktionieren. durch das OEM-System-Image und das Referenz-AOSP-System-Image, das von Google bereitgestellt wird. (und CTS an dieses Referenzbild übergeben). Diese Anforderungen stellen eine saubere vom Framework und vom Anbietercode getrennt. Diese Geräte unterstützen die folgenden Szenarien.

Nur-Anbieter-Bilderweiterungen

Beispiel: Neuen Dienst zu vndservicemanager hinzufügen aus dem Anbieter-Image, das Prozesse aus dem Anbieter-Image unterstützt.

Wie bei Geräten, die mit früheren Android-Versionen auf den Markt gebracht werden, fügen Sie gerätespezifische Anpassung in device/manufacturer/device-name/sepolicy Neue Richtlinie, die festlegt, wie Komponenten des Anbieters (nur) mit anderen Anbietern interagieren Komponenten sollten Typen umfassen, die nur in device/manufacturer/device-name/sepolicy Die hier verfasste Richtlinie lässt zu, dass Code für den Anbieter funktioniert. Er wird nicht als Teil aktualisiert. eines reinen Framework-OTA und ist in der kombinierten Richtlinie auf einem Gerät vorhanden mit dem Referenz-AOSP-System-Image.

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

Beispiel: Hinzufügen eines neuen Prozesses (registriert mit hwservicemanager aus dem Anbieterbild), mit dem ein AOSP-definiertes HAL.

Wie bei Geräten, die mit früheren Android-Versionen auf den Markt gebracht werden, solltet ihr gerätespezifische Anpassung device/manufacturer/device-name/sepolicy Die Richtlinie, die als Teil von system/sepolicy/public/ exportiert wurde, ist verfügbar zur Verwendung und wird als Teil der Anbieterrichtlinien geliefert. Typen und Attribute von kann die Public Policy in neuen Regeln, die Interaktionen mit den neuen anbieterspezifische Bits, vorbehaltlich der angegebenen neverallow Einschränkungen. Wie im Fall nur für Anbieter wird die neue Richtlinie hier nicht aktualisiert. ist Teil eines OTA-Frameworks und wird in der kombinierten Richtlinie auf einem Gerät mit dem Referenz-AOSP-System-Image.

Erweiterungen nur mit System-Image

Beispiel: Neuen Dienst hinzufügen (registriert bei Servicemanager) auf die nur andere Prozesse aus dem System-Image zugreifen.

Diese Richtlinie zu system/sepolicy/private hinzufügen. Sie können weitere Prozesse oder Objekte, um Funktionen in einem Partnersystem-Image zu ermöglichen, sofern Diese neuen Teile müssen nicht mit neuen Komponenten im Anbieterbild interagieren. (Insbesondere müssen solche Prozesse oder Objekte ohne Richtlinie der Bild des Anbieters). Die von system/sepolicy/public exportierte Richtlinie ist genau wie für reine Anbieter-Image-Erweiterungen. Diese Richtlinie ist Teil des System-Images und könnte in einem Framework-OTA-Update aktualisiert werden, wird jedoch nicht vorhanden sein, wenn das Referenz-AOSP-System-Image verwendet wird.

Anbieterbild Erweiterungen, die erweiterte AOSP-Komponenten bereitstellen,

Beispiel:Ein neuer Nicht-AOSP-HAL zur Verwendung durch erweiterte Clients, die auch im AOSP-System-Image vorhanden sind (z. B. ein erweiterter system_server).

Richtlinie für die Interaktion zwischen System und Anbieter muss in der device/manufacturer/device-name/sepolicy das in der Anbieterpartition ausgelieferte Verzeichnis. Dies ähnelt dem oben beschriebenen Szenario, bei dem Sie die Unterstützung für das Anbieter-Image hinzufügen. mit dem Referenz-AOSP-Image, außer dass die modifizierten AOSP-Komponenten auch für eine ordnungsgemäße Funktion mit dem Rest des Systems zusätzliche Richtlinien erforderlich. (was in Ordnung ist, solange sie noch den öffentlichen AOSP-Typ Labels).

Richtlinie für die Interaktion öffentlicher AOSP-Komponenten mit reinem System-Image Erweiterungen müssen auf system/sepolicy/private sein.

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

Beispiel:Ein neuer Nicht-AOSP-Systemprozess muss auf einen HAL in auf die sich AOSP stützt.

Dies ähnelt der Methode Nur System-Image Erweiterungsbeispiel, nur dass neue Systemkomponenten im gesamten system/vendor-Schnittstelle. Richtlinie für die neue Systemkomponente muss Dies ist unter der Voraussetzung erlaubt, dass system/sepolicy/private über eine Schnittstelle, die bereits von AOSP in system/sepolicy/public (d.h. die Typen und Attribute, die für Funktionen vorhanden sind). Die Richtlinie kann zwar in den gerätespezifischen können keine anderen system/sepolicy/private- Arten oder Änderungen (mit Auswirkungen auf die Richtlinien) infolge eines reinen Framework aktualisieren. Die Richtlinie kann in einem reinen Framework-OTA-Update geändert werden, wird jedoch nicht vorhanden ist, wenn ein AOSP-System-Image verwendet wird (das das neue System Komponente).

Anbieterbild Erweiterungen, die neue Systemkomponenten

Beispiel:Hinzufügen eines neuen Nicht-AOSP-HAL zur Verwendung durch einen Clientprozess ohne ein AOSP-Analog (und erfordert daher eine eigene Domain).

Ähnlich wie die AOSP-extensions Beispiel: Die Richtlinie für Interaktionen zwischen System und Anbieter muss in den device/manufacturer/device-name/sepolicy Verzeichnis in der Anbieterpartition Dadurch wird sichergestellt, dass die Systemrichtlinie keine anbieterspezifischen Details kennt. Ich können neue öffentliche Typen hinzufügen, die die Richtlinie in system/sepolicy/public; sollte dies nur zusätzlich zum vorhandene AOSP-Richtlinie, d.h. entfernen Sie die öffentliche AOSP-Richtlinie nicht. Die neue Öffentlichkeit Typen können dann für Richtlinien in system/sepolicy/private und in device/manufacturer/device-name/sepolicy.

Beachten Sie, dass mit jeder Hinzufügung von system/sepolicy/public durch eine neue Kompatibilitätsgarantie, die in einem -Zuordnungsdatei, die anderen Einschränkungen unterliegt. Nur neue Typen und können entsprechende Zulassungsregeln in system/sepolicy/public hinzugefügt werden. Attribute und andere Richtlinienanweisungen werden nicht unterstützt. Außerdem sind neue öffentlichen Typen können nicht verwendet werden, um Objekte im /vendor-Richtlinie.

Nicht unterstützte Richtlinienszenarien

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

Zusätzliche Informationen Erweiterungen für System-Image, für die eine Berechtigung erforderlich ist auf neue Komponenten des Anbieterbilds nachdem ein reines Framework-OTA-

Beispiel : Ein neuer Nicht-AOSP-Systemprozess, der einen eigenen Domain, wird mit der nächsten Android-Version hinzugefügt und benötigt Zugriff auf eine neue, Nicht-AOSP HAL.

Ähnlich wie neu Interaktion des (nicht AOSP)-Systems und der Anbieterkomponenten mit Ausnahme des neuen Systems wird in einer bestimmten auf das Framework beschränkt. Obwohl der neue Typ der Richtlinie in system/sepolicy/public, in der vorhandenen Anbieterrichtlinie liegen keine Informationen vor des neuen Typs, da damit nur die öffentlichen Richtlinien des Android 8.0-Systems erfasst werden. AOSP bewältigt dies, indem vom Anbieter bereitgestellte Ressourcen über ein Attribut (z.B. hal_foo-Attribut), aber als Attribut für Partnererweiterungen wird in system/sepolicy/public unterstützt, ist diese Methode für Anbieterrichtlinie. Der Zugriff muss über einen zuvor vorhandenen öffentlichen Typ bereitgestellt werden.

Beispiel : Eine Änderung an einem Systemprozess (AOSP oder Nicht-AOSP) muss die Interaktion mit neuen, Nicht-AOSP-Anbieterkomponente ändern.

Die Richtlinie für das System-Image muss ohne Kenntnis bestimmter für die Anbieteranpassungen. Die Richtlinie zu spezifischen Schnittstellen in AOSP ist daher werden über Attribute in system/sepolicy/public bereitgestellt, damit die Anbieterrichtlinie aktivieren Sie zukünftige Systemrichtlinien, in denen diese Attribute verwendet werden. Sie können jedoch Attributerweiterungen in system/sepolicy/public sind nicht unterstützt, sodass alle Richtlinien vorgeben, wie die Systemkomponenten interagieren. mit neuen Anbieterkomponenten (und die nicht bereits von Attributen gehandhabt werden) vorhanden in AOSP system/sepolicy/public) muss in device/manufacturer/device-name/sepolicy. Das bedeutet, dass sich Systemtypen nicht Zugriff auf Anbietertypen im Rahmen eines reinen Framework-OTA