Implementieren von SELinux

SELinux ist auf default-deny eingestellt, was bedeutet, dass jeder einzelne Zugriff, für den es einen Hook im Kernel hat, explizit per Policy erlaubt werden muss. Dies bedeutet, dass eine Richtliniendatei eine große Menge an Informationen zu Regeln, Typen, Klassen, Berechtigungen und mehr enthält. Eine vollständige Betrachtung von SELinux würde den Rahmen dieses Dokuments sprengen, aber ein Verständnis für das Schreiben von Richtlinienregeln ist jetzt unerlässlich, wenn neue Android-Geräte eingeführt werden. Es gibt bereits viele Informationen zu SELinux. Siehe Begleitdokumentation für vorgeschlagene Ressourcen.

Schlüsseldateien

So aktivieren Sie SELinux, integrieren die neuesten Android - Kernel und dann übernehmen die Dateien in dem gefundenen System / sepolicy Verzeichnis. Wenn sie kompiliert sind, umfassen diese Dateien die SELinux-Kernel-Sicherheitsrichtlinie und decken das vorgelagerte Android-Betriebssystem ab.

Im Allgemeinen sollten Sie das nicht ändern system/sepolicy Dateien direkt. Stattdessen fügen oder bearbeiten Sie Ihre eigenen gerätespezifischen Richtliniendateien im /device/ manufacturer / device-name /sepolicy Verzeichnis. In Android 8.0 und höher sollten sich die Änderungen, die Sie an diesen Dateien vornehmen, nur auf die Richtlinien in Ihrem Anbieterverzeichnis auswirken. Weitere Einzelheiten über die Trennung von öffentlichen sepolicy in Android 8.0 und höher, siehe Customizing SEPolicy in Android 8.0+ . Unabhängig von der Android-Version ändern Sie immer noch diese Dateien:

Richtliniendateien

Dateien , die Ende mit *.te sind SELinux - Policy - Quelldateien, die Domänen und ihre Etiketten definieren. Sie können neue Richtliniendateien in erstellen müssen /device/ manufacturer / device-name /sepolicy , aber Sie sollten versuchen , vorhandene Dateien zu aktualisieren , soweit möglich.

Kontextdateien

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

  • file_contexts Abtretungs Etikett auf Dateien und wird von verschiedenen User - Space - Komponenten verwendet. Wenn Sie neue Richtlinien erstellen, erstellen oder aktualisieren Sie diese Datei, um den Dateien neue Labels zuzuweisen. Um neue Anwendung file_contexts , erstellen Sie die Dateisystem - Image oder laufen restorecon auf die Datei neu gekennzeichnet werden. Auf Upgrades, Änderungen an file_contexts an dem System und Benutzerdaten Partitionen als Teil des Upgrades automatisch übernommen. Änderungen können auch automatisch auf andere Partitionen auf Upgrade angewendet werden , indem restorecon_recursive Anrufe an Ihre init. board RC - Datei nach der Teilung wurde read-write montiert.
  • genfs_contexts Abtretungs Labels Dateisysteme, wie proc oder vfat die nicht erweiterte Attribute unterstützen. Diese Konfiguration wird als Teil der Kernel-Richtlinie geladen, aber Änderungen werden möglicherweise nicht für In-Core-Inodes wirksam, was einen Neustart oder das Aushängen und erneute Einhängen des Dateisystems erfordert, um die Änderung vollständig zu übernehmen. Spezielle Etiketten können auch auf spezielle Halterungen zugeordnet werden, wie vfat die mit context=mount - Option.
  • property_contexts Abtretungs Etiketten Android Systemeigenschaften zu steuern , welche Prozesse sie einstellen können. Diese Konfiguration wird durch das Lesen init Prozess während des Starts.
  • service_contexts Abtretungs Etiketten Android Bindemittel Dienste zu kontrollieren , welche Prozesse hinzufügen können (registrieren) und (Lookup) ein Bindemittel Referenz für den Service. Diese Konfiguration wird durch das Lesen servicemanager Prozess während des Starts.
  • seapp_contexts Abtretungs Etiketten App Prozesse und /data/data Diese Konfiguration wird durch das Lesen zygote Prozess auf jedem App - Start und durch installd während des Starts.
  • mac_permissions.xml Zessionäre seinfo - Tag - Anwendungen anhand ihrer Signatur und deren Paketnamen optional. Die seinfo - Tag kann dann als Schlüssel in der verwendet werden seapp_contexts Datei ein bestimmtes Etikett für alle Anwendungen mit , dass zuweisen seinfo Tag. Diese Konfiguration wird durch Lesen system_server während des Starts.

BoardConfig.mk-Makefile

Nach dem Bearbeiten oder Hinzufügen von Dateien Politik und Kontext, aktualisieren Sie Ihre /device/ manufacturer / device-name /BoardConfig.mk Make - Datei , die auf Referenz sepolicy Unterverzeichnis und jede neue Richtliniendatei. Weitere Informationen über die BOARD_SEPOLICY Variablen finden system/sepolicy/README - Datei .

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

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Nach dem Wiederaufbau ist Ihr Gerät mit SELinux aktiviert. Sie können nun Ihre SELinux - Richtlinien passen Sie Ihre eigenen Ergänzungen des Android - Betriebssystem aufzunehmen , wie in beschrieben Anpassung oder überprüfen Sie Ihre vorhandenen Setup wie in abgedeckt Validation .

Wenn die neuen Richtliniendateien und BoardConfig.mk-Updates vorhanden sind, werden die neuen Richtlinieneinstellungen automatisch in die endgültige Kernel-Richtliniendatei integriert. Weitere Informationen darüber , wie sepolicy auf dem Gerät eingebaut ist, siehe Gebäude sepolicy .

Implementierung

Um mit SELinux zu beginnen:

  1. Aktivieren SELinux im Kernel: CONFIG_SECURITY_SELINUX=y
  2. Ändern Sie den kernel_cmdline oder bootconfig Parameter , so dass:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    oder
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Dies ist nur für die anfängliche Entwicklung der Politik für das Gerät. Nachdem Sie eine anfängliche Bootstrap-Richtlinie festgelegt haben, entfernen Sie diesen Parameter, damit Ihr Gerät erzwingt oder CTS fehlschlägt.
  3. Starten Sie das System permissiv und sehen Sie, welche Ablehnungen beim Booten auftreten:
    Unter Ubuntu 14.04 oder neuer:
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    
    auf Ubuntu 12.04:
    adb pull /sys/fs/selinux/policy
    adb logcat -b all | audit2allow -p policy
    
  4. Beurteilen Sie die Ausgabe für Warnungen , die ähneln init: Warning! Service name needs a SELinux domain defined; please fix! Siehe Validation Anleitungen und Werkzeuge.
  5. Identifizieren Sie Geräte und andere neue Dateien, die gekennzeichnet werden müssen.
  6. Verwenden Sie bestehende oder neue Labels für Ihre Objekte. Schauen Sie sich die *_contexts Dateien , um zu sehen , wie die Dinge vorher markiert und Verwendung Kenntnis der Etiketten Bedeutungen einen neuen zu vergeben. Im Idealfall ist dies ein bestehendes Label, das in die Politik passt, aber manchmal wird ein neues Label benötigt, und es werden Regeln für den Zugang zu diesem Label benötigt. Fügen Sie Ihre Labels zu den entsprechenden Kontextdateien hinzu.
  7. Identifizieren Sie Domänen/Prozesse, die ihre eigenen Sicherheitsdomänen haben sollten. Sie müssen wahrscheinlich für jede eine komplett neue Richtlinie schreiben. Alle Leistungen aus gelaicht init , zum Beispiel, sollten ihre eigenen haben. Die folgenden Befehle helfen dabei, diejenigen aufzudecken, die weiterhin ausgeführt werden (aber ALLE Dienste benötigen eine solche Behandlung):
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. Überprüfen Sie init. device .rc alle Domänen zu identifizieren , die nicht über einen Domain - Typen haben. Geben Sie ihnen eine Domain früh in dem Entwicklungsprozess Hinzufügen von Regeln zu vermeiden init oder sonst verwirrend init greift mit denen , die in ihrer eigenen Politik sind.
  9. Set up BOARD_CONFIG.mk verwenden BOARD_SEPOLICY_* Variablen. Sehen Sie sich die Readme - in system/sepolicy Einzelheiten über diese Einrichtung.
  10. Untersuchen Sie die Initialisierung. device .rc und fstab. device und stellt sicher , dass jeder Einsatz von mount entspricht ein korrekt beschriftetes Dateisystem oder dass ein context= mount - Option angegeben ist.
  11. Gehen Sie jede Ablehnung durch und erstellen Sie eine SELinux-Richtlinie, um jede ordnungsgemäß zu behandeln. Beispiele finden Sie in Customization .

Sie sollten mit den Richtlinien im AOSP beginnen und dann für Ihre eigenen Anpassungen darauf aufbauen. Weitere Informationen über die politische Strategie und einen genaueren Blick auf einige dieser Schritte finden Writing SELinux - Politik .

Anwendungsfälle

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

Symlinks - Weil Symlinks als Dateien erscheinen, werden sie oft als Dateien lesen, die zu Taten führen kann. Zum Beispiel, einige privilegierten Komponenten, wie init , ändern Sie die Berechtigungen für bestimmte Dateien, manchmal übermäßig geöffnet zu sein.

Angreifer können diese Dateien dann durch symbolische Links zu dem von ihnen kontrollierten Code ersetzen, sodass der Angreifer beliebige Dateien überschreiben kann. Wenn Sie jedoch wissen, dass Ihre Anwendung niemals einen Symlink durchlaufen wird, können Sie dies mit SELinux verhindern.

Systemdateien - Betrachten Sie die Klasse von Systemdateien , die nur durch den System - Server geändert werden soll. Doch seit netd , init und vold Lauf als Wurzel, können sie diese Systemdateien zugreifen. Also , wenn netd kompromittiert wurde, könnte es diese Dateien beeinträchtigen und möglicherweise den Systemserver selbst.

Mit SELinux können Sie diese Dateien als Systemserver-Datendateien identifizieren. Daher ist die einzige Domäne, die Lese-/Schreibzugriff darauf hat, der Systemserver. Auch wenn netd kompromittiert wurde, kann es nicht wechseln Domänen zur System - Server - Domäne und Zugriff auf diese Systemdateien , obwohl es als root läuft.

App - Daten - Ein weiteres Beispiel ist die Klasse von Funktionen , die als root ausführen müssen, soll aber nicht den Zugriff auf App - Daten erhalten. Dies ist unglaublich nützlich, da weitreichende Behauptungen aufgestellt werden können, z.

setattr - Für Befehle wie chmod und chown , könnten Sie den Satz von Dateien identifizieren , wo die zugehörige Domäne durchführen kann setattr . Alles, was darüber hinausgeht, könnte von diesen Änderungen ausgeschlossen werden, sogar von root. So könnte eine Anwendung laufen chmod und chown gegen die markierten app_data_files aber nicht shell_data_files oder system_data_files .