Das Android-Sicherheitsmodell

Android gibt eine Reihe von Berechtigungen vor, so z. B. die Berechtigung, Telefonfunktionen zu nutzen oder das Netzwerk zu verwenden. Wichtiger weiterer Eckpfeiler ist auch der Zugriff auf durch den Content-Provider gekapselte Daten. Android deklariert dutzende verschiedene Berechtigungen wie den Zugriff auf Netzwerk, GPS, das Abfangen eingehender SMS oder auch Zugriff auf Kamera und Ähnliches.

Die Durchsetzung der eingenommenen Berechtigungen wird auf verschiedenen Ebenen der Plattform erreicht. Zwei Eckpfeiler sind dabei die Benutzeridentität der Applikation sowie die Benutzergruppen (Linux GIDs), in denen die Benutzeridentität Mitglied ist. Die Berechtigung zur Verwendung von Netzwerkfunktionalität wird z. B. anhand der Mitgliedschaft in einer speziellen Linux-Gruppe (Gruppe inet) ermittelt. Die entsprechende Kontrolle der Zugehörigkeit zur Gruppe wird auf Kernel-Ebene durchgeführt, wofür Android eine Kernel-Modifikation verwendet.

Die Genehmigungen werden zusätzlich in so genannte Risk-Levels unterteilt, die darüber entscheiden, wie das System mit den Berechtigungen umzugehen hat. Man unterscheidet die Stufen normal, dangerous, signature und systemOrSignature. Alle mit dem Risk-Level normal deklarierten Genehmigungen werden der anfordernden Applikation automatisch ohne Benutzernachfrage zugeteilt. Der Benutzer kann bei der Installation diese Genehmigungen jedoch einsehen. Bei dangerous werden die angeforderten Genehmigungen dem Nutzer bei der Installation einer Applikation zur expliziten Zustimmung vorgelegt. Berechtigungen dieser Stufe haben einen direkten Einfluss auf das Gerät, andere Applikation oder Benutzerdaten. Insbesondere können sie mehr Kontrolle über das Gerät übernehmen, als eventuell gewünscht. Eine mit signature deklarierte Genehmigung kann nur dann erteilt werden, wenn die deklarierende Applikation mit demselben Zertifikat unterschrieben ist, wie die Applikation, die diese Genehmigung einnehmen will. Ist dies der Fall, wird die Genehmigung automatisch erteilt. Berechtigungen der Stufe systemOrSignature werden nur den Applikationen erteilt, die mit dem System-Image ausgeliefert wurden oder das gleiche Zertifikat aufweisen wie Applikationen, die mit dem System-Image ausgeliefert wurden.

Das Genehmigungskonzept folgt dem Alles-oder-nichts-Konzept: Der Benutzer muss entweder der Installation und damit allen angeforderten Genehmigungen zustimmen oder den Abbruch der Installation veranlassen. Alle einmal erteilten Genehmigungen können zu jeder Zeit im Paketmanager eingesehen, jedoch nicht entzogen werden; es steht lediglich die komplette Deinstallation der Applikation zur Verfügung (Abb. 3).

Abb. 3: Ansicht der Berechtigungen einer Applikation im Paketmanager von Android
Datenabstraktion

Ein weiterer Sicherheitsmechanismus wurde für den Zugriff auf Daten des Systems und anderer Applikationen entwickelt. Es muss Applikationen möglich sein, auf Daten anderer Applikationen oder des Systems zugreifen zu können. Dabei muss jedoch gewährleistet werden, dass dies nur unter Durchsetzung der Sicherheitsrichtlinien möglich ist. Daher hat jede Applikation ein eigens für sich abgeschlossenes Heimatverzeichnis, in das sie Daten nur für ihre eigene Lese- und Schreibberechtigung ablegt. Dies geschieht auf Basis des üblichen Linux-Discretionary-Access-Control-Modells, das für jede Datei definierbar macht, ob nur ein bestimmter Benutzer, eine Benutzergruppe, oder „alle“ entweder Lese-, Schreib- oder Ausführungsberechtigung haben. Da jede Applikation unter einer exklusiven Benutzeridentität läuft, lässt sich eine Datei einer anderen Applikation nur dann lesen oder beschreiben, wenn sie „für alle“ zugreifbar ist. Das ist nur durch das explizite Setzen des WORLD_READABLE beziehungsweise WORLD_WRITABLE Flags bei der Dateianlage möglich. Von einem solchen Vorgehen ist jedoch abzuraten, da Android mit dem Konzept der Content-Provider eine elegantere Möglichkeit der Datenabstraktion bereitstellt. Mit ihrer Hilfe wird ebenfalls gewährleistet, dass das Berechtigungssystem auch für den Zugriff auf fremde Daten verwendet werden kann. Berechtigungen können sogar für lesenden und schreibenden Zugriff einzeln deklariert werden. Dabei werden die Berechtigungen geprüft, wenn die Applikation einen Providerzugang anfordert sowie auch bei jeder Operation auf dem Provider. Ein Beispiel für eine Zugriffsberechtigung auf einen von Android ausgelieferten Content-Provider ist die READ_CONTACTS-Berechtigung, die den Zugriff auf den Content-Provider für die Kontaktdaten erlaubt.

Content-Provider verwenden ebenfalls ein feingranulares Berechtigungskonzept für URIs, die den Ort der Daten spezifizieren. Das Konzept der URI-Berechtigungen erlaubt es, dass ein Content-Provider sehr spezifisch den Zugriff auf ein bestimmtes Datum erteilt, das unter einer spezifizierten URI zu finden ist und zwischen Applikationen geteilt werden soll. Es kann dabei schreibender oder lesender Zugriff erlaubt werden. Gibt beispielsweise eine E-Mail-Applikation die URI, unter der ein spezifisches Attachement zu finden ist, an den entsprechenden Handler weiter, braucht diesem nicht der komplette Zugriff auf E-Mail-Daten erlaubt werden, sondern lediglich der Zugriff auf das eine Attachement.

Zugriffsrechte auf Partitionsebene

Um die höchstmögliche Sicherheit vor Systemmodifikationen zu gewährleisten, wurde ebenfalls der grundsätzliche Dateisystemaufbau überdacht und im Gegensatz zu einem Standard-Aufbau auf dem Linux-Desktop angepasst. Systemkritische Daten und ausführbare Dateien werden unterhalb von /system/ abgelegt. Applikationsdaten werden in /data/ abgelegt. Die /system-Partition ist per Vorgabe nur lesend eingehängt. Auf ihr befinden sich alle Programme und Systemdienste der Android-Plattform. Zu diesen gehören auch die standardmäßig ausgelieferten Applikationen wie Kontaktmanagement, Telefonapplikation u. Ä. Dies verhindert auf Betriebssystemebene das Überschreiben von Systemkomponenten. Für den Austausch von Android-Applikationen, die mit dem System ausgeliefert wurden, z. B. die Telefonapplikation, wird eine Ausnahmebehandlung verwendet, indem ein lokales Overlay angelegt wird. Die Applikation wird in die /data-Partition installiert und der Paketmanager „verbirgt“ die ältere Variante auf der Systempartition.

Da Android ebenfalls die Möglichkeit bietet, externe Medien automatisiert einzubinden, wurde auch hier ein Trick angewendet. Um zu verhindern, dass nativer Schadcode über ein externes Medium eingeschleust wird, werden Medien mit der Option noexec eingehangen. So verhindert der Linux-Kernel, dass Programme, die auf einem externen Medium eingebunden werden, überhaupt ausgeführt werden können.

Applikationssignaturen

Jede Android-Applikation muss vom Entwickler mit einer Signatur versehen werden, die den Entwickler eindeutig identifiziert. Dabei ist es unerheblich, ob diese vom Entwickler in den Android-Market gestellt oder direkt installiert wird. Der Paketmanager verweigert sonst die Installation der Applikation. Der private Schlüssel verbleibt dabei ausschließlich im Besitz des Entwicklers. Eine zentrale Zertifikatsautorität, die die Authentizität der Signatur garantiert, ist nicht zwingend erforderlich; es besteht jedoch die Möglichkeit, Zertifikate von einer Autorität unterschreiben zu lassen. Zurzeit existiert jedoch keine zentrale Autorität von Google, daher ist es auch möglich, selbstsignierte Zertifikate zu verwenden. Die Zertifikate werden jedoch nur für Vertrauensbeziehungen zwischen den installierten Applikationen verwendet. Sie kontrollieren einerseits, ob die Applikation berechtigt ist, auf signaturbasierte Berechtigungen zuzugreifen, und andererseits, ob zwei Applikationen unter derselben Benutzer-ID laufen dürfen und somit eine größere Vertrauensbeziehung zueinander haben, als zwei sich fremde Applikationen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.