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 neuefile_contexts
an: Erstellen Sie das Dateisystem-Image neu oder führen Sierestorecon
für die Datei aus, beschriftet werden. Bei Upgrades sind die Änderungen anfile_contexts
: automatisch auf die System- und Nutzerdatenpartitionen als Teil der ein Upgrade ausführen. Änderungen können auch automatisch beim Upgrade auf andere indem Sierestorecon_recursive
-Aufrufe zu Ihrem init.board.rc nach der Bereitstellung der Partition Lese-/Schreibzugriff.genfs_contexts
weist Dateisystemen Labels zu, z. B.proc
odervfat
, 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 Optioncontext=mount
.property_contexts
weist den Android-Systemeigenschaften Labels zu welche Prozesse sie festlegen können. Diese Konfiguration wird vominit
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 vomservicemanager
beim Start.seapp_contexts
weist App-Prozessen und App-Prozessen Labels zu/data/data
Verzeichnisse. Diese Konfiguration wird vomzygote
-Prozess bei jedem App-Start und bisinstalld
beim Start.mac_permissions.xml
weist Apps einseinfo
-Tag zu basierend auf der Signatur und optional dem Paketnamen. Die Das Tagseinfo
kann dann als Schlüssel imseapp_contexts
-Datei, um allen Apps mit einem bestimmten Label ein bestimmtes Label zuzuweisen diesesseinfo
-Tag. Diese Konfiguration wird vonsystem_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
<ph type="x-smartling-placeholder">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
oderBOARD_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 zuinit
oder dieinit
-Zugriffe mit denen verwirren, die sich in ihrer eigenen Richtlinie. BOARD_CONFIG.mk
einrichten, umBOARD_SEPOLICY_*
zu verwenden Variablen. Weitere Informationen finden Sie in der README insystem/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 einecontext= 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