Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

SELinux implementieren

SELinux ist auf Standardverweigerung eingestellt, was bedeutet, dass jeder einzelne Zugriff, für den es einen Hook im Kernel hat, von der Richtlinie explizit zugelassen 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 Berücksichtigung von SELinux fällt nicht in den Geltungsbereich dieses Dokuments. Wenn Sie jedoch neue Android-Geräte aufrufen, ist es jetzt wichtig zu verstehen, wie Richtlinienregeln geschrieben werden. Zu SELinux sind bereits viele Informationen verfügbar. Die empfohlenen Ressourcen finden Sie in der unterstützenden Dokumentation .

Schlüsseldateien

Um SELinux zu aktivieren, integrieren Sie den neuesten Android-Kernel und integrieren Sie dann die Dateien im Verzeichnis system / sepolicy . Beim Kompilieren enthalten diese Dateien die Sicherheitsrichtlinie des SELinux-Kernels und decken das vorgelagerte Android-Betriebssystem ab.

Im Allgemeinen sollten Sie die system/sepolicy Dateien nicht direkt ändern. /device/ manufacturer / device-name /sepolicy stattdessen Ihre eigenen gerätespezifischen Richtliniendateien im Verzeichnis /device/ manufacturer / device-name /sepolicy hinzu oder bearbeiten Sie sie. In Android 8.0 und höher sollten sich die Änderungen, die Sie an diesen Dateien vornehmen, nur auf die Richtlinien in Ihrem Herstellerverzeichnis auswirken. Weitere Informationen zur Trennung der öffentlichen Sicherheit in Android 8.0 und höher finden Sie unter Anpassen von SEPolicy in Android 8.0+ . Unabhängig von der Android-Version ändern Sie immer noch diese Dateien:

Richtliniendateien

Dateien, die mit *.te sind SELinux-Richtlinienquelldateien, die Domänen und ihre Bezeichnungen definieren. Möglicherweise müssen Sie neue Richtliniendateien in /device/ manufacturer / device-name /sepolicy , aber Sie sollten versuchen, vorhandene Dateien nach Möglichkeit zu aktualisieren.

Kontextdateien

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

  • file_contexts weist Dateien Beschriftungen zu und wird von verschiedenen Userspace-Komponenten verwendet. Erstellen oder aktualisieren Sie diese Datei beim Erstellen neuer Richtlinien, um Dateien neue Beschriftungen zuzuweisen. Um neue file_contexts anzuwenden, file_contexts das Dateisystem-Image neu oder führen Sie restorecon für die neu zu kennzeichnende Datei aus. Bei Upgrades werden Änderungen an file_contexts im Rahmen des Upgrades automatisch auf die System- und Benutzerdatenpartitionen angewendet. Änderungen können auch beim Upgrade auf andere Partitionen automatisch übernommen werden, indem restorecon_recursive Ihrem init restorecon_recursive Aufrufe hinzufügen. board RC-Datei, nachdem die Partition mit Lese- und Schreibzugriff bereitgestellt wurde.
  • genfs_contexts weist Dateisystemen wie proc oder vfat , die keine erweiterten Attribute unterstützen. Diese Konfiguration wird als Teil der Kernelrichtlinie geladen, Änderungen werden jedoch möglicherweise nicht für Inodes im Kern wirksam. Dies erfordert einen Neustart oder das Aufheben und Bereitstellen des Dateisystems, um die Änderung vollständig anzuwenden. Bestimmte Beschriftungen können auch bestimmten vfat zugewiesen werden, z. B. vfat mithilfe der Option context=mount .
  • property_contexts weist Android-Systemeigenschaften Beschriftungen zu, um zu steuern, welche Prozesse sie festlegen können. Diese Konfiguration wird beim Start vom init Prozess gelesen.
  • service_contexts weist Android-Binder-Diensten Beschriftungen zu, um zu steuern, welche Prozesse eine Binder-Referenz für den Dienst hinzufügen (registrieren) und suchen (nachschlagen) können. Diese Konfiguration wird vom servicemanager während des Startvorgangs gelesen.
  • seapp_contexts weist App-Prozessen und /data/data Verzeichnissen Beschriftungen zu. Diese Konfiguration wird beim Start der App vom zygote Prozess gelesen und beim Start installd .
  • 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 Datei seapp_contexts werden, um allen Apps mit diesem seinfo Tag eine bestimmte Bezeichnung seinfo . Diese Konfiguration wird beim Start von system_server gelesen.

BoardConfig.mk Makefile

Aktualisieren Sie nach dem Bearbeiten oder Hinzufügen von Richtlinien- und Kontextdateien Ihr Makefile /device/ manufacturer / device-name /BoardConfig.mk um auf das Unterverzeichnis sepolicy und jede neue Richtliniendatei zu verweisen. 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 Wiederherstellen wird Ihr Gerät mit SELinux aktiviert. Sie können jetzt entweder Ihre SELinux-Richtlinien anpassen, um Ihre eigenen Ergänzungen zum Android-Betriebssystem zu berücksichtigen, wie unter Anpassung beschrieben, oder Ihr vorhandenes Setup gemäß Validierung überprüfen.

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

Implementierung

So starten Sie mit SELinux:

  1. Aktivieren Sie SELinux im Kernel: CONFIG_SECURITY_SELINUX=y
  2. Ändern Sie den Parameter kernel_cmdline so, dass:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    Dies ist nur für die anfängliche Entwicklung der Richtlinie für das Gerät. Entfernen Sie diesen Parameter, nachdem Sie eine erste Bootstrap-Richtlinie erstellt haben, damit Ihr Gerät dies erzwingt. Andernfalls schlägt CTS fehl.
  3. Starten Sie das System in zulässiger Weise 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
    
    Unter Ubuntu 12.04:
    adb pull /sys/fs/selinux/policy
    adb logcat -b all | audit2allow -p policy
    
  4. Bewerten Sie die Ausgabe auf Warnungen, die init: Warning! Service name needs a SELinux domain defined; please fix! ähneln init: Warning! Service name needs a SELinux domain defined; please fix! Anweisungen und Tools finden Sie unter Validierung .
  5. Identifizieren Sie Geräte und andere neue Dateien, die beschriftet werden müssen.
  6. Verwenden Sie vorhandene oder neue Beschriftungen für Ihre Objekte. Sehen Sie sich die *_contexts Dateien an, um zu sehen, wie die Dinge zuvor beschriftet wurden, und verwenden Sie die Kenntnis der Beschriftungsbedeutungen, um eine neue zuzuweisen. Im Idealfall handelt es sich hierbei um ein vorhandenes Etikett, das in die Richtlinie passt. Manchmal wird jedoch ein neues Etikett benötigt, und es werden Regeln für den Zugriff auf dieses Etikett benötigt. Fügen Sie Ihre Beschriftungen 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 völlig neue Richtlinie schreiben. Alle von init Dienste sollten beispielsweise ihre eigenen haben. Die folgenden Befehle helfen dabei, diejenigen anzuzeigen, die noch ausgeführt werden (ALLE Dienste benötigen jedoch 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 , um alle Domänen zu identifizieren, die keinen init. device .rc haben. Geben Sie ihnen zu Beginn Ihres Entwicklungsprozesses eine Domäne, um zu vermeiden, dass init Regeln hinzugefügt werden, oder um init Zugriffe auf andere Weise mit solchen zu verwechseln, die in ihrer eigenen Richtlinie enthalten sind.
  9. BOARD_CONFIG.mk , dass BOARD_SEPOLICY_* BOARD_CONFIG.mk verwendet werden. system/sepolicy Informationen zum Einrichten finden Sie in der README- system/sepolicy in system/sepolicy .
  10. Untersuche den Init. device .rc und fstab. device und stellen Sie sicher, dass jede Verwendung von mount einem ordnungsgemäß gekennzeichneten Dateisystem entspricht oder dass eine Option context= mount angegeben ist.
  11. Gehen Sie jede Ablehnung durch und erstellen Sie eine SELinux-Richtlinie, um jede ordnungsgemäß zu behandeln. Siehe die Beispiele unter Anpassung .

Sie sollten mit den Richtlinien im AOSP beginnen und dann für Ihre eigenen Anpassungen darauf aufbauen. Weitere Informationen zur Richtlinienstrategie und einen genaueren Blick auf einige dieser Schritte finden Sie unter Schreiben von SELinux-Richtlinien .

Anwendungsfälle

Im Folgenden finden Sie einige Beispiele für Exploits, die beim Erstellen Ihrer eigenen Software und der zugehörigen SELinux-Richtlinien berücksichtigt werden müssen:

Symlinks - Da Symlinks als Dateien angezeigt werden, werden sie häufig als Dateien gelesen, was zu Exploits führen kann. Beispielsweise ändern einige privilegierte Komponenten, wie z. B. init , die Berechtigungen bestimmter Dateien, sodass sie manchmal übermäßig geöffnet sind.

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

Systemdateien - Betrachten Sie die Klasse der Systemdateien, die nur vom Systemserver geändert werden sollten. Da netd , init und vold als root ausgeführt werden, können sie dennoch auf diese Systemdateien zugreifen. Wenn netd kompromittiert wird, kann es diese Dateien und möglicherweise den netd selbst kompromittieren.

Mit SELinux können Sie diese Dateien als Systemserver-Datendateien identifizieren. Daher ist die einzige Domäne, die Lese- / Schreibzugriff auf sie hat, der Systemserver. Selbst wenn netd kompromittiert wurde, konnte es keine Domänen zur netd 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 nicht auf App-Daten zugreifen dürfen. Dies ist unglaublich nützlich, da weitreichende Aussagen getroffen werden können, beispielsweise bestimmte Domänen, die nicht mit Anwendungsdaten in Verbindung stehen und denen der Zugriff auf das Internet untersagt ist.

setattr - Bei Befehlen wie chmod und chown können Sie die Dateien identifizieren, in denen die zugeordnete Domäne setattr . Alles außerhalb davon könnte von diesen Änderungen ausgeschlossen werden, auch 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 .