Diese Seite wurde von der Cloud Translation API übersetzt.

Implementierung von SELinux

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. Umfassende Übersicht ü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 eine Es gibt bereits zahlreiche 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 bilden diese Dateien die SELinux-Kernel-Sicherheit. und decken das vorgelagerte Android-Betriebssystem ab.

Im Allgemeinen sollten Sie die system/sepolicy-Dateien nicht ändern. . Fügen Sie stattdessen eigene gerätespezifische Richtliniendateien im /device/manufacturer/device-name/sepolicy -Verzeichnis. Unter Android 8.0 und höher sollten die Änderungen, die Sie an diesen Dateien vornehmen, wirken sich nur auf die Richtlinie in Ihrem Anbieterverzeichnis aus. 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-Richtlinienquelldateien, die Domains und deren Labels zu definieren. Möglicherweise müssen Sie neue Richtliniendateien /device/manufacturer/device-name/sepolicy, Sie sollten aber versuchen, vorhandene Dateien nach Möglichkeit 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. 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 indem Sie restorecon_recursive-Aufrufe zu Ihrem init.board.rc nach der Bereitstellung der Partition Lese-/Schreibzugriff.
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, bei In-Core-Inodes, 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 vom init beim Start.
service_contexts weist den Android-Binder-Diensten Labels zu Steuern, welche Prozesse einen Binder hinzufügen (registrieren) und finden (suchen) können Referenz für den Dienst. 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 bis installd beim Start.
mac_permissions.xml weist Apps ein seinfo-Tag zu basierend auf der Signatur und optional dem Paketnamen. Die Das Tag seinfo kann dann als Schlüssel im seapp_contexts-Datei, um allen Apps mit einem bestimmten Label ein bestimmtes Label zuzuweisen dieses seinfo-Tag. Diese Konfiguration wird von system_server beim Start.
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 sepolicy. definierten Namespaces. Eine detaillierte Beschreibung des Formats und der Konventionen 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 <ph type="x-smartling-placeholder"></ph> system/sepolicy/README-Datei.

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

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Nach der Neuerstellung wird 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 Sie Ihre 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 zu sepolicy auf dem Gerät finden Sie unter Sicherheitsrichtlinie für Gebäude.

Implementierung

Erste Schritte mit SELinux:

Aktivieren Sie SELinux im Kernel: CONFIG_SECURITY_SELINUX=y
Ändern Sie den Parameter „Kernel_cmdline“ oder „Bootconfig“ so:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
oder
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
Dies ist nur für die anfängliche Entwicklung einer Richtlinie für das Gerät vorgesehen. Nachdem Sie eine anfängliche Bootstrap-Richtlinie hat, entfernen Sie diesen Parameter, erzwingt oder schlägt CTS fehl.

Starten Sie das System mit dem Modus „Moderat“ und prüfen Sie, welche Ablehnungen beim Starten 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, um zu sehen, wie Elemente zuvor mit Labels versehen wurden und nutzen Sie die Bedeutung der Labels, um ihnen ein neues zuzuweisen. Idealerweise ist dies ein vorhandenes Label, das in die Richtlinie passt, aber manchmal ist ein neues Label erforderlich. Die Regeln für den Zugriff auf dieses Label erforderlich. Fügen Sie Ihre Labels den entsprechenden Kontextdateien hinzu.
Identifizieren Sie Domains/Prozesse, die ihre eigenen Sicherheitsdomains haben sollten. Wahrscheinlich musst du für jede Gruppe eine neue Richtlinie erstellen. Alle Dienste, die beispielsweise aus init erzeugt wurden, sollten ihre gehören. Mit den folgenden Befehlen können Sie diejenigen anzeigen, die noch ausgeführt werden (aber ALLE Dienste erfordern eine solche Behandlung):
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
Überprüfen Sie init.device.rc, um alle Domains zu ermitteln, 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 finden Sie in der README in system/sepolicy finden Sie weitere Informationen zur Einrichtung.
Sehen Sie sich die Dateien init.device.rc und fstab.device an und jede Verwendung von mount einem ordnungsgemäßen 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 erscheinen, was zu Exploits führen kann. Einige privilegierte Personen Komponenten wie init die Berechtigungen für bestimmte Dateien ändern, manchmal sehr offen sein.

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 niemals durchlaufen, 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 gehackt wurde, und möglicherweise auch den Systemserver selbst.

Mit SELinux können Sie diese Dateien als Systemserverdatendateien identifizieren. Daher ist die einzige Domain, die Lese-/Schreibzugriff darauf hat, der Systemserver. Selbst wenn netd manipuliert wurde, konnte die Domain nicht auf den Systemserver-Domain und greifen auf diese Systemdateien zu, obwohl er als Root ausgeführt wird.

App-Daten: Ein weiteres Beispiel ist die Klasse von Funktionen, die muss als Root ausgeführt werden, sollte aber nicht auf App-Daten zugreifen können. Das ist unglaublich ist nützlich, da weitreichende Behauptungen aufgestellt werden können, z. B. bestimmte Domains, die keinen Bezug zueinander haben oder Anwendungsdaten, 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 könnte auch von der Root-Ebene ausgeschlossen. 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