Android 4.3 und SELinux

Vor einigen Wochen veröffentlichte Google die neuste Version seines Flaggschiffs – das mobile Betriebssystem Android 4.3. Auch wenn so mancher meint, dass es diesmal reichlich wenig Updates gäbe, so hat es vom Sicherheitsstandpunkt einige unbestreitbare Verbesserungen mit sich gebracht (unter anderem wurde die „MasterKey“-Sicherheitslücke endlich gepatcht). Eine der herausragenden Neuheiten ist SELinux. Von vielen wurde es als längst überfälliger Schritt gefeiert, andere kritisierten die Einführung. Ich persönlich denke, dass der Einfluss nicht so ohne weiteres abzuschätzen ist, insbesondere wenn es um den Nutzen für die Endanwender geht. Um ein wenig Licht in die Angelegenheit zu bringen, konnten wir nicht anders und analysierten, was SELinux eigentlich ist und welchen Einfluss es in diesem Fall hat.

9180

Android JellyBean 4.3 Logo

Beginnen wir mit den Grundlagen: Die Sicherheit jedes auf Linux basierenden Systems beruht auf dem Konzept Discretionary Access Control (DAC), was bedeutet, dass jeder Anwender selbst entscheidet, auf welche seiner Dateien von anderen Usern zugegriffen werden kann (lesen, schreiben oder ausführen). Das System selbst wird vor Einmischung geschützt, da alle Systemdateien der administrativen User-‚Root‘ gehören. Android basiert auf genau denselben Konzepten, allerdings mit einer kleinen, aber maßgeblichen Ergänzung: Jeder App wird eine andere User-ID zugeordnet (einige Ausnahmen sind trotzdem möglich), so dass die Anwendungsdaten isoliert und vor allen anderen Anwendungen geschützt werden. Das ist der Grund, warum es auf nicht „Nicht-Root“- Geräten recht schwierig, wenn nicht gar unmöglich für eine legitime Anwendung ist, private Daten zu stehlen, die von einer anderen App genutzt werden (natürlich nur, wenn die Daten nicht auf „weltlesbar“ eingestellt sind).

DAC bedeutet, dass der Zugriff auf Dateien und Ressourcen
nach User- und Datei/Verzeichnis-Modi definiert wird

SELinux fußt darauf (sowie auf 15 Jahren Betriebssystem-Sicherheitsentwicklung durch die NSA) und ergänzt eine weitere Sicherheitsebene mit der Bezeichnung Mandatory Access Control (MAC). Diese Ebene, die durch systemweite Policies konfiguriert wird, regelt zudem wie Anwender (und auch Apps auf Android-Geräten) sowohl auf ihre eigenen Daten als auch auf die vom System bereitgestellten Daten zugreifen, und zwar alles überaus transparent.

Technisch ausgedrückt ist es möglich, Policies zu entwerfen, die in der Lage sind, die Art der Interaktionen zu spezifizieren, die ein Prozess, der als Teil eines Sicherheitskontexts konfiguriert ist, durchführen kann oder nicht. Ein einfaches, aber nach wie vor einleuchtendes Beispiel ist der Fall eines System Log Daemons, der mit Rootrechten (ouch) läuft. Mit SELinux können wir das ursprüngliche System so konfigurieren, dass der Prozess auf nichts anderes als auf die Log-Datei zugreifen kann: Wir müssten der Log-Datei zu diesem Zweck nur ein spezielles Label zuordnen und eine Policy schreiben, die es dem Log-Daemon erlaubt, nur auf Dateien mit diesem Label zuzugreifen (wie immer muss man berücksichtigen, dass es in Wahrheit alles ein bisschen komplizierter ist :)). Zwei Vorteile ergeben sich aus dieser Sichtweise: 1. Die Policy kann systemweit implementiert werden (und selbst Rootrechte müssen sich unterordnen); 2. Die Benutzerrechte sind sehr viel detaillierter als die möglicherweise von der DAC definierten.

Die Möglichkeit, den Aktionsradius des Superusers zu beschränken (ungeachtet seiner Rechte) ist von zentraler Bedeutung für den Schutz des Systems vor Attacken mit unautorisierter Erhöhung der Privilegien („privilege escalation attacks“). Dadurch zeichnet sich SELinux aus. Nehmen wir mal den Fall Gingerbreak, ein weit verbreitetes Exploit für die Root von auf Gingerbread basierenden Geräten. Das Exploit schickte eine sorgfältig erstellte Netlink-Nachricht an den Volume-Daemon (vold), der als Root läuft. Aufgrund einiger nicht durchgeführter obligatorischer Überprüfungen kann diese Nachricht zur erfolgreichen Einschleusung und Ausführung von Code führen. Da der Prozess als Root läuft, ist es in der Tat kein Ding, ein Setuid-Root-Shell zu setzen und von da an die Kontrolle über das Gerät zu übernehmen. SELinux hingegen hätte das Exploit gestoppt, indem die besagte Nachricht abgewiesen worden wäre: Die Standard-Policy (zumindest im Original Patch-Set) verweigert das Öffnen dieses Socket-Typs, das Problem ist also gelöst. Als wäre das nicht genug, kann die Ausführung von nicht systeminternen-Binärdateien durch den Daemon-Prozess im weiteren Verlauf auch durch eine andere SELinux-Policy verhindert werden.

Nicht markierte FS nach OTA-Update.

Das klingt super, oder? Doch leider ist es weit von der Realität entfernt. Der SELinux-Implementation auf Android 4.3 fehlen derzeit einige wichtige Merkmale. Erstens ist SELinux nur im Permissiven Modus konfiguriert, das bedeutet Policies werden nicht durchgesetzt, und Verletzungen werden nur protokolliert. Wie oben zu sehen ist, bezeichnet das OTA-Update die Systempartitionen nicht korrekt (mein Testgerät ließ mich für eine Weile ziemlich ratlos dastehen, bis ich rausfand, dass der Forscher Pau Oliva genau dieselbe Erkenntnis auf der DEF CON 21 veröffentlicht hat), das bedeutet das ein Stock-Restore unumgänglich ist, wenn ein Entwickler es testen will. Abgesehen davon, dass die eingesetzten Policies alles andere als restriktiv sind, ist kein MAC für Android-Middleware verfügbar (ein Feature statt eines Teils des NSA Patch-Sets).

Was bedeutet das nun für den Endanwender? So wie’s derzeit aussieht, leider nicht viel. So wie auf Android 4.3 implementiert, kann SELinux lediglich getestet und Policies können entwickelt werden. Es gibt keine sichere Art, sie durchzusetzen. Jetzt ist in der Tat die Zeit der OEM-Anbieter gekommen. Google fördert nachdrücklich die Entwicklungen von SELinux-Implementationen (irgendwer BYOD?), die auf Stock-Funktionalitäten basieren – eher als auf zusammengeschusterten Add-Ons (hier wieder ein Verweis auf die DEFCON 21 für eine ausführliche Erklärung, was „Implementationsaspekte“ bedeuten können). Entwickler werden auf der anderen Seite dazu aufgefordert, sich mit den Standard-Policies vertraut zu machen und ihre Apps darauf zu testen. Werden wir je eine Android-Veröffentlichung mit SELinux im Enforce-Modus erleben? Das bleibt zumindest zu hoffen 🙂

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.