Sicherheitsoptimiertes Linux in Android

Als Teil des Android- Sicherheitsmodells verwendet Android Security-Enhanced Linux (SELinux), um die obligatorische Zugriffskontrolle (MAC) für alle Prozesse durchzusetzen, sogar für Prozesse, die mit Root-/Superuser-Berechtigungen (Linux-Fähigkeiten) ausgeführt werden. Viele Unternehmen und Organisationen haben zur SELinux-Implementierung von Android beigetragen. Mit SELinux kann Android Systemdienste besser schützen und einschränken, den Zugriff auf Anwendungsdaten und Systemprotokolle kontrollieren, die Auswirkungen bösartiger Software reduzieren und Benutzer vor potenziellen Fehlern im Code auf Mobilgeräten schützen.

SELinux arbeitet nach dem Prinzip der Standardverweigerung: Alles, was nicht ausdrücklich erlaubt ist, wird verweigert. SELinux kann in zwei globalen Modi betrieben werden:

  • Berechtigungsmodus , in dem Berechtigungsverweigerungen protokolliert, aber nicht erzwungen werden.
  • Erzwingungsmodus , in dem die Verweigerung von Berechtigungen sowohl protokolliert als auch erzwungen wird.

Android enthält SELinux im Erzwingungsmodus und eine entsprechende Sicherheitsrichtlinie, die standardmäßig über AOSP funktioniert. Im Erzwingungsmodus werden unzulässige Aktionen verhindert und alle versuchten Verletzungen werden vom Kernel in dmesg und logcat . Bei der Entwicklung sollten Sie diese Fehler verwenden, um Ihre Software und SELinux-Richtlinien zu verfeinern, bevor Sie sie durchsetzen. Weitere Einzelheiten finden Sie unter Implementieren von SELinux .

SELinux unterstützt auch einen permissiven Modus pro Domäne , in dem bestimmte Domänen (Prozesse) zulassend gemacht werden können, während der Rest des Systems in den globalen Erzwingungsmodus versetzt wird. Eine Domäne ist einfach eine Bezeichnung, die einen Prozess oder eine Reihe von Prozessen in der Sicherheitsrichtlinie identifiziert, wobei alle Prozesse, die mit derselben Domäne gekennzeichnet sind, von der Sicherheitsrichtlinie identisch behandelt werden. Der permissive Modus pro Domäne ermöglicht die inkrementelle Anwendung von SELinux auf einen ständig wachsenden Teil des Systems und die Richtlinienentwicklung für neue Dienste (während der Rest des Systems die Durchsetzung aufrechterhält).

Hintergrund

Das Android-Sicherheitsmodell basiert teilweise auf dem Konzept von Anwendungs-Sandboxen . Jede Anwendung läuft in einer eigenen Sandbox. Vor Android 4.3 wurden diese Sandboxes durch die Erstellung einer eindeutigen Linux-UID für jede Anwendung zum Zeitpunkt der Installation definiert. Android 4.3 und höher verwendet SELinux, um die Grenzen der Android-Anwendungs-Sandbox weiter zu definieren.

In Android 5.0 und höher wird SELinux vollständig durchgesetzt, aufbauend auf der freizügigen Veröffentlichung von Android 4.3 und der teilweisen Durchsetzung von Android 4.4. Mit dieser Änderung verlagerte sich Android von der Durchsetzung auf eine begrenzte Anzahl wichtiger Domains ( installd , netd , vold und zygote ) auf alles (mehr als 60 Domains). Speziell:

  • In Android 5.x und höher befindet sich alles im Erzwingungsmodus.
  • In der init Domäne sollten außer init keine anderen Prozesse ausgeführt werden.
  • Jede generische Verweigerung (für ein block_device , socket_device , default_service ) zeigt an, dass das Gerät eine spezielle Domäne benötigt.

Android 6.0 hat das System gehärtet, indem die Freizügigkeit unserer Richtlinie reduziert wurde, um eine bessere Isolierung zwischen Benutzern, IOCTL-Filterung, reduzierte Bedrohung durch exponierte Dienste, eine weitere Verschärfung der SELinux-Domänen und einen extrem eingeschränkten /proc Zugriff einzuschließen.

Android 7.0 hat die SELinux-Konfiguration aktualisiert, um die Anwendungs-Sandbox weiter zu sperren und die Angriffsfläche zu reduzieren. Diese Version hat auch den monolithischen Medienserver-Stack in kleinere Prozesse aufgeteilt, um den Umfang ihrer Berechtigungen zu reduzieren. Weitere Einzelheiten finden Sie unter Schützen von Android mit mehr Abwehrmechanismen für den Linux-Kernel und Härten des Medienstapels .

Android 8.0 hat SELinux aktualisiert, um mit Treble zu arbeiten, wodurch der untergeordnete Anbietercode vom Android-Systemframework getrennt wird. In dieser Version wurde die SELinux-Richtlinie aktualisiert, um es Geräteherstellern und SOC-Anbietern zu ermöglichen, ihre Teile der Richtlinie zu aktualisieren, ihre Images zu erstellen ( vendor.img , boot.img usw.) und diese Images dann unabhängig von der Plattform zu aktualisieren oder umgekehrt.

Es ist zwar möglich, eine höhere/neuere Plattformversion (Framework) auf dem Gerät auszuführen, der umgekehrte Fall wird jedoch nicht unterstützt; Die Anbieter-Images ( vendor.img/odm.img ) dürfen keine neuere Version als die Plattform ( system.img ) haben. Daher kann eine neuere Plattformversion zu SELinux-Kompatibilitätsproblemen führen, da die Plattform-SELinux-Richtlinie eine neuere Version als die SELinux-Teile des Anbieters der Richtlinie aufweist. Das Android 8.0-Modell bietet eine Methode zur Beibehaltung der Kompatibilität , um unnötige gleichzeitige OTAs zu vermeiden.

Zusätzliche Ressourcen

Hilfe beim Erstellen nützlicher SELinux-Richtlinien finden Sie in den folgenden Ressourcen. Einige SELinux-Konzepte werden von Android nicht verwendet, siehe den Abschnitt „ Spezifität “, wenn Sie externe Dokumentation in Betracht ziehen.