Diese Seite wurde von der Cloud Translation API übersetzt.

SELinux implementieren

SELinux ist auf "default-deny" eingestellt, was bedeutet, dass jeder einzelne Zugriff für die über einen Hook im Kernel verfügt, muss von der Richtlinie explizit erlaubt sein. Dieses bedeutet, dass eine Richtliniendatei eine große Menge an Informationen zu Regeln, Typen, Klassen, Berechtigungen und mehr. Umfassender Überblick über SELinux wird in diesem Dokument nicht behandelt, aber wenn Sie wissen, sind bei der Einführung neuer Android-Geräte jetzt wesentlich mehr. Es gibt bereits viele Informationen zu SELinux. Weitere Informationen finden Sie unter in der Dokumentation.

Schlüsseldateien

Integrieren Sie zum Aktivieren von SELinux neueste Android-Kernel und integrieren dann die Dateien aus der system/sepolicy -Verzeichnis. Nach der Kompilierung enthalten diese Dateien die SELinux-Kernelsicherheitsrichtlinie und decken das Upstream-Android-Betriebssystem ab.

Im Allgemeinen sollten Sie die system/sepolicy-Dateien nicht direkt ändern. Fügen Sie stattdessen eigene gerätespezifische Richtliniendateien im /device/manufacturer/device-name/sepolicy -Verzeichnis. Unter Android 8.0 und höher sollten sich die Änderungen, die Sie an diesen Dateien vornehmen, nur auf die Richtlinie in Ihrem Anbieterverzeichnis auswirken. Weitere Informationen zur Trennung von Public sepolicy in Android 8.0 und höher finden Sie unter SEPolicy in Android anpassen 8.0 oder höher. Diese Dateien ändern Sie unabhängig von der Android-Version weiterhin:

Richtliniendateien

Dateien, die auf *.te enden, sind SELinux-Richtlinienquellendateien, in denen Domains und ihre Labels definiert werden. Möglicherweise müssen Sie neue Richtliniendateien in /device/manufacturer/device-name/sepolicy erstellen. Versuchen Sie jedoch nach Möglichkeit, vorhandene Dateien zu aktualisieren.

Kontextdateien

In Kontextdateien geben Sie Labels für Ihre Objekte an.

file_contexts weist Dateien Labels zu und wird von verschiedenen Userspace-Komponenten verwendet. Wenn Sie neue Richtlinien erstellen, erstellen oder aktualisieren Sie diese Datei, um Dateien neue Labels zuzuweisen. So wenden Sie neue file_contexts an: Erstellen Sie das Dateisystem-Image neu oder führen Sie restorecon für die Datei aus, beschriftet werden. Bei Upgrades sind die Änderungen an file_contexts: automatisch auf die System- und Nutzerdatenpartitionen als Teil der ein Upgrade ausführen. Änderungen können auch automatisch beim Upgrade auf andere Partitionen angewendet werden, indem Sie der Datei „init.board.rc“ restorecon_recursive-Aufrufe hinzufügen, nachdem die Partition schreibgeschützt bereitgestellt wurde.
genfs_contexts weist Dateisystemen Labels zu, z. B. proc oder vfat, die erweiterte Funktionen nicht unterstützen Attribute. Diese Konfiguration wird als Teil der Kernel-Richtlinie geladen, werden möglicherweise keine Änderungen für In-Core-Inodes wirksam, die einen Neustart oder das Dateisystem trennen und wieder bereitstellen, um die Änderung vollständig zu übernehmen. Bestimmte Halterungen können auch bestimmten Kennzeichnungen zugewiesen werden, z. B. vfat mit der Option context=mount.
property_contexts weist den Android-Systemeigenschaften Labels zu welche Prozesse sie festlegen können. Diese Konfiguration wird beim Starten vom Prozess init gelesen.
service_contexts ordnet Android-Binderdiensten Labels zu, um zu steuern, welche Prozesse eine Binderreferenz für den Dienst hinzufügen (registrieren) und finden (abrufen) können. Diese Konfiguration wird vom servicemanager beim Start.
seapp_contexts weist App-Prozessen und App-Prozessen Labels zu /data/data Verzeichnisse. Diese Konfiguration wird vom zygote-Prozess bei jedem App-Start und von installd beim Start gelesen.
mac_permissions.xml weist Apps basierend auf ihrer Signatur und optional ihrem Paketnamen ein seinfo-Tag zu. Das seinfo-Tag kann dann als Schlüssel in der seapp_contexts-Datei verwendet werden, um allen Apps mit diesem seinfo-Tag ein bestimmtes Label zuzuweisen. Diese Konfiguration wird beim Starten von system_server gelesen.
keystore2_key_contexts weist Namespaces von Keystore 2.0 Labels zu. Diese Namespaces werden vom keystore2-Daemon erzwungen. Schlüsselspeicher hat UID/AID-basierte Namespaces angegeben. Keystore 2.0 erzwingt zusätzlich Namespaces, die in der SEPolicy definiert sind. Eine detaillierte Beschreibung des Formats und der Konventionen dieser Datei finden Sie hier.

BoardConfig.mk-Makefile

Nachdem Sie Richtlinien- und Kontextdateien bearbeitet oder hinzugefügt haben, aktualisieren Sie Ihre /device/manufacturer/device-name/BoardConfig.mk Makefile, um auf das Unterverzeichnis sepolicy und jede neue Richtliniendatei zu verweisen. Weitere Informationen zu den Variablen BOARD_SEPOLICY finden Sie unter system/sepolicy/README-Datei.

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Nach dem Neuaufbau ist SELinux auf Ihrem Gerät aktiviert. Sie können jetzt entweder können Sie Ihre SELinux-Richtlinien an Ihre eigenen Ergänzungen Android-Betriebssystem, wie in Anpassung oder bestätigen wie in den Validierung:

Wenn die neuen Richtliniendateien und BoardConfig.mk-Updates vorhanden sind, werden die neuen Die Richtlinieneinstellungen sind automatisch in die endgültige Kernel-Richtliniendatei integriert. Weitere Informationen zum Erstellen von sepolicy auf dem Gerät finden Sie unter sepolicy erstellen.

Implementierung

Erste Schritte mit SELinux:

Aktivieren Sie SELinux im Kernel: CONFIG_SECURITY_SELINUX=y
Ändern Sie den Parameter „kernel_cmdline“ oder „bootconfig“ so, dass:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
oder
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
Dies gilt nur für die Erstentwicklung der Richtlinie für das Gerät. Nachdem Sie eine erste Bootstrap-Richtlinie festgelegt haben, entfernen Sie diesen Parameter, damit Ihr Gerät die Richtlinie erzwingt oder den CTS-Test nicht besteht.

Starten Sie das System im permissive-Modus und sehen Sie nach, welche Zugriffsverweigerungen beim Start auftreten:
Unter Ubuntu 14.04 oder höher:

adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy

Unter Ubuntu 12.04:

adb pull /sys/fs/selinux/policy
adb logcat -b all | audit2allow -p policy

Bewerten Sie die Ausgabe auf Warnungen wie init: Warning! Service name needs a SELinux domain defined; please fix!. Siehe Validierung für Anleitungen und Tools.
Geräte und andere neue Dateien ermitteln, die mit einem Label versehen werden müssen
Verwenden Sie vorhandene oder neue Labels für Ihre Objekte. Sehen Sie sich die *_contexts-Dateien an, um zu sehen, wie die Elemente zuvor gekennzeichnet waren, und weisen Sie anhand der Bedeutungen der Labels ein neues zu. Idealerweise ist dies ein vorhandenes Label, das den Richtlinien entspricht. Manchmal ist jedoch ein neues Label und Regeln für den Zugriff auf dieses Label erforderlich. Fügen Sie die Labels den entsprechenden Kontextdateien hinzu.
Domains/Prozesse identifizieren, die ihre eigenen Sicherheitsdomains haben sollten Wahrscheinlich musst du für jede Gruppe eine neue Richtlinie erstellen. Alle Dienste, die von init stammen, sollten beispielsweise eigene haben. Mit den folgenden Befehlen können Sie herausfinden, welche Dienste noch ausgeführt werden. ALLE Dienste müssen jedoch so behandelt werden:
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
Prüfen Sie init.device.rc, um Domains zu finden, die keinen Domaintyp haben. Weisen Sie ihnen eine Domain frühzeitig in Ihrem Entwicklungsprozess, um das Hinzufügen von Regeln zu init oder die init-Zugriffe mit denen verwirren, die sich in ihrer eigenen Richtlinie.
BOARD_CONFIG.mk einrichten, um BOARD_SEPOLICY_* zu verwenden Variablen. Weitere Informationen zur Einrichtung finden Sie in der README-Datei in system/sepolicy.
Prüfen Sie die Dateien „init.device.rc“ und „fstab.device“ und achten Sie darauf, dass jede Verwendung von mount einem korrekt beschrifteten Dateisystem entspricht oder dass eine context= mount-Option angegeben ist.
Gehen Sie jede Ablehnung durch und erstellen Sie eine SELinux-Richtlinie, um jede Ablehnung ordnungsgemäß zu verarbeiten. Weitere Informationen finden Sie unter die Beispiele unter Anpassung.

Sie sollten mit den Richtlinien im AOSP beginnen und dann darauf aufbauen. Anpassungen vornehmen. Weitere Informationen zur Richtlinienstrategie und sehen wir uns einige dieser Schritte genauer an. SELinux-Richtlinie schreiben.

Anwendungsfälle

Hier sind konkrete Beispiele für Exploits, die Sie bei der Erstellung eigener Exploits berücksichtigen sollten. Software und zugehörige SELinux-Richtlinien:

Symlinks:Da Symlinks als Dateien angezeigt werden, was zu Exploits führen kann. Beispielsweise ändern einige privilegierte Komponenten wie init die Berechtigungen bestimmter Dateien, manchmal zu weitreichend.

Angreifer könnten diese Dateien dann durch Symlinks ersetzen, um den von ihnen kontrollierten Code sodass Angreifer beliebige Dateien überschreiben können. Aber wenn Sie wissen, einen Symlink nie durchsucht, können Sie dies verbieten. mit SELinux.

Systemdateien:Berücksichtigen Sie die Klasse der Systemdateien, sollte nur vom Systemserver geändert werden. Seit netd init und vold werden als Root ausgeführt und haben Zugriff Systemdateien. Wenn netd also manipuliert wird, könnten diese Dateien und möglicherweise auch der Systemserver selbst manipuliert werden.

Mit SELinux können Sie diese Dateien als Systemserverdatendateien identifizieren. Daher ist die einzige Domain, die Lese-/Schreibzugriff auf sie hat, der Systemserver. Selbst wenn netd manipuliert würde, könnte es nicht zur Systemserverdomain wechseln und auf diese Systemdateien zugreifen, obwohl es als Root ausgeführt wird.

App-Daten: Ein weiteres Beispiel ist die Klasse von Funktionen, die als Root ausgeführt werden müssen, aber keinen Zugriff auf App-Daten erhalten sollten. Das ist unglaublich ist nützlich, da weitreichende Behauptungen aufgestellt werden können, z. B. bestimmte Domains, die in keinem Zusammenhang stehen für App-Daten, die keinen Zugriff auf das Internet haben.

setattr:Für Befehle wie chmod und chown können Sie die Gruppe von Dateien ermitteln, in denen die verknüpften Domain setattr durchführen kann. Alles andere kann von diesen Änderungen ausgeschlossen werden, auch durch Root. Eine Anwendung kann also chmod und chown im Vergleich zu den mit dem Label versehenen app_data_files, aber nicht shell_data_files oder system_data_files