Security-Enhanced Linux in Android

Im Rahmen des Sicherheitsmodells von Android wird Security-Enhanced Linux (SELinux) verwendet, um die obligatorische Zugriffssteuerung (MAC) für alle Prozesse durchzusetzen, auch für Prozesse, die mit Root-/Superuser-Berechtigungen (Linux-Funktionen) 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 steuern, die Auswirkungen von Schadsoftware reduzieren und Nutzer vor potenziellen Fehlern im Code auf Mobilgeräten schützen.

SELinux basiert auf dem Prinzip der Standardablehnung: Alles, was nicht explizit zugelassen ist, wird abgelehnt. SELinux kann in zwei globalen Modi ausgeführt werden:

  • Moderater Modus, bei dem abgelehnte Berechtigungen protokolliert, aber nicht erzwungen werden.
  • Enforcing-Modus, bei dem verweigerte Berechtigungen protokolliert und erzwungen werden.

Android enthält SELinux im Erzwingungsmodus und eine entsprechende Sicherheitsrichtlinie, die standardmäßig in AOSP funktioniert. Im Erzwingungsmodus werden nicht zulässige Aktionen verhindert und alle versuchten Verstöße werden vom Kernel in dmesg und logcat protokolliert. Während der Entwicklung sollten Sie diese Fehler nutzen, um Ihre Software und SELinux-Richtlinien zu optimieren, bevor Sie sie erzwingen. Weitere Informationen finden Sie unter SELinux implementieren.

SELinux unterstützt auch einen pro-Domain-Modus mit permissiven Zugriffsrechten, in dem bestimmte Domains (Prozesse) als „permissive“ festgelegt werden können, während der Rest des Systems im globalen Erzwingungsmodus bleibt. Eine Domain ist einfach ein Label, das einen Prozess oder mehrere Prozesse in der Sicherheitsrichtlinie identifiziert. Alle Prozesse, die mit derselben Domain gekennzeichnet sind, werden von der Sicherheitsrichtlinie identisch behandelt. Der zulassende Modus pro Domain ermöglicht die schrittweise Anwendung von SELinux auf einen immer größeren Teil des Systems und die Richtlinienentwicklung für neue Dienste, während der Rest des Systems weiterhin erzwungen wird.

Hintergrund

Das Android-Sicherheitsmodell basiert teilweise auf dem Konzept von Anwendungs-Sandboxes. Jede Anwendung wird in einer eigenen Sandbox ausgeführt. Vor Android 4.3 wurden diese Sandboxes durch das Erstellen einer eindeutigen Linux-UID für jede Anwendung bei der Installation definiert. Unter Android 4.3 und höher werden die Grenzen der Android-Anwendungs-Sandbox mit SELinux weiter definiert.

In Android 5.0 und höher wird SELinux vollständig erzwungen. Dabei wird auf die permissive Version von Android 4.3 und die teilweise Erzwingung von Android 4.4 aufgebaut. Durch diese Änderung wurde die Durchsetzung von einer begrenzten Anzahl wichtiger Domains (installd, netd, vold und zygote) auf alle Domains (mehr als 60 Domains) ausgeweitet. Im Detail:

  • Unter Android 5.x und höher ist alles im Erzwingungsmodus.
  • Außer init sollten keine weiteren Prozesse in der Domain init ausgeführt werden.
  • Jede allgemeine Ablehnung (für block_device, socket_device oder default_service) bedeutet, dass für das Gerät eine spezielle Domain erforderlich ist.

In Android 6.0 wurde das System durch eine Verschärfung unserer Richtlinien gehärtet. So wurde unter anderem die Isolation zwischen Nutzern verbessert, IOCTL-Filter eingeführt, die Bedrohung durch freigegebene Dienste reduziert, SELinux-Domains weiter verschärft und der /proc-Zugriff stark eingeschränkt.

Unter Android 7.0 wurde die SELinux-Konfiguration aktualisiert, um die Anwendungs-Sandbox weiter zu sperren und die Angriffsfläche zu verringern. Außerdem wurde der monolithische Mediaserver-Stack in kleinere Prozesse aufgeteilt, um den Umfang ihrer Berechtigungen zu reduzieren. Weitere Informationen finden Sie unter Android mit mehr Linux-Kernel-Schutzmaßnahmen schützen und Media-Stack härten.

In Android 8.0 wurde SELinux für die Verwendung mit Treble aktualisiert, wodurch der Anbietercode der unteren Ebene vom Android-System-Framework getrennt wird. Mit dieser Version wurde die SELinux-Richtlinie aktualisiert, damit Gerätehersteller und SOC-Anbieter ihre Teile der Richtlinie aktualisieren, ihre Images (vendor.img, boot.img usw.) erstellen und diese Images dann unabhängig von der Plattform aktualisieren können 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. Eine neuere Plattformversion kann also SELinux-Kompatibilitätsprobleme verursachen, da die SELinux-Richtlinie der Plattform eine neuere Version als die SELinux-Teile der Richtlinie des Anbieters hat. Das Android 8.0-Modell bietet eine Methode, um die Kompatibilität beizubehalten und unnötige gleichzeitige OTAs zu vermeiden.

Weitere Informationen

In den folgenden Ressourcen finden Sie Informationen zum Erstellen nützlicher SELinux-Richtlinien.