Google schaffte 2005 mit dem Zukauf des Unternehmens Android den Einstieg in das Segment der mobilen Plattformen. Entwickelt unter dem Dach der von Google initiierten Open Handset Alliance (OHA)avancierte das gleichnamige Betriebssystem inzwischen zur meistverbreiteten mobilen Plattform. Maßgebend für die rasante Entwicklung von Android ist die Lizenzpolitik der Open Handset Alliance, die das Betriebssystem den Herstellern von Mobiltelefonen zur freien Verfügung stellt.
Kern des Betriebssystems ist ein für den mobilen Einsatz optimierter Linux-Kernel, sowie zahlreiche Treiber und Bibliotheken aus dessen Umfeld. Wesentliches Merkmal von Android ist die Verwendung der Programmiersprache Java. Den Java-Bytecode von Anwendungen interpretiert die Dalvik Virtual Machine (DVM), eine von Google für den Betrieb auf mobilen Endgeräten angepasste Java-Laufzeitumgebung.
Jede Anwendung läuft unter Android in einem eigenen Prozess und in einer eigenen Instanz der Dalvik Virtual Machine. Dies gilt auch für die vorinstallierten Anwendungen, zu denen der Browser oder die Email-Applikation zählen. Zentrale Komponente des Betriebssystems ist das Programm Zygote. Als Masterprozess der Dalvik Virtual Machine ist Zygote für das Starten und Verwalten aller Applikationen verantwortlich. Beim Start des Android-Betriebssystems lädt Zygote häufig verwendete Bibliotheken in einen globalen Speicherbereich, so dass diese mit anderen Applikationen gemeinsam verwendet werden können. Anschließend öffnet Zygote einen Socket und wartet auf eingehende Anfragen zum Starten von Applikationen. Erhält Zygote eine entsprechende Nachricht, erzeugt es durch den Systemaufruf fork() eine neue Instanz der Dalvik Virtual Machine und startet die Applikationen mit einem gleichzeitigen Wechsel in deren Benutzerkontext.
Die Isolation der Applikationen bewerkstelligt der zugrunde liegende Linux-Kernel. Hierfür vergibt der Paketmanager zum Installationszeitpunkt jeder Android-Anwendung eine exklusive Benutzeridentität (UID). Welche UID der Paketmanager einer Applikation zugeordnet hat, speichert Android in einer XML-Struktur in der Datei /data/system/packages.xml. Listing 1 zeigt unter anderem die Benutzeridentität der im Android-Market kostenlos verfügbaren Anwendung "Twitter".
<!-- /data/system/packages.xml -->
...
<package name="com.twitter.android" codePath="/data/app/com.twitter.android.apk" system="false" ts="1312815675000" version="134" userId="10065" installer="com.google.android.feedback">
...
<perms>
<item name="android.permission.USE_CREDENTIALS" />
<item name="android.permission.WRITE_EXTERNAL_STORAGE" />
<item name="android.permission.GET_ACCOUNTS" />
<item name="android.permission.READ_CONTACTS" />
<item name="android.permission.WRITE_CONTACTS" />
<item name="android.permission.AUTHENTICATE_ACCOUNTS" />
<item name="android.permission.WRITE_SYNC_SETTINGS" />
<item name="com.twitter.android.permission.RESTRICTED" />
<item name="android.permission.INTERNET" />
<item name="com.twitter.android.permission.READ_DATA" />
<item name="android.permission.ACCESS_FINE_LOCATION" />
<item name="android.permission.READ_SYNC_SETTINGS" />
<item name="android.permission.MANAGE_ACCOUNTS" />
<item name="android.permission.VIBRATE" />
<item name="android.permission.WAKE_LOCK" />
<item name="com.twitter.android.permission.C2D_MESSAGE" />
...
</perms>
</package>
...
<package name="com.lge.hidden_camera" codePath="/system/app/CameraTest.apk" system="true" ts="1294384488000" version="7" sharedUserId="10005">
...
<package name="com.android.providers.drm" codePath="/system/app/DrmProvider.apk" system="true" ts="1294384488000" version="7" sharedUserId="10005">
...
Listing 1: Zuordnung von UIDs und Applikationen in der packages.xml
Kein Zugriff auf fremde Verzeichnisse
Zygote startet Applikationen im Kontext der in dieser Datei festgelegten Benutzeridentität. Die Abschirmung der einzelnen Applikationen untereinander übernimmt die Prozessisolation des Linux-Kernels.
Foto: VikaSuh/Shutterstock, Buchstabensuppe
Dieser Sandboxmechanismus greift nicht nur auf Prozess-, sondern auch auf Dateisystemebene. Neben einer eindeutigen Benutzeridentität weist der Paketmanager bei der Installation jeder Applikation ein eigenes abgeschlossenes Heimatverzeichnis unterhalb von /data/data/ zu, in welchem die Applikationen ihre Daten ablegen können. Andere Applikationen oder Prozesse haben auf Daten in diesem Verzeichnis standardmäßig keinen Zugriff. Die Zugriffskontrolle erfolgt auf Basis der klassischen UNIX Discretionary Access Control (DAC). Bei diesem Sicherheitskonzept weist das Betriebssystem jeder Datei und jedem Verzeichnis einen Besitzer zu und vergibt jeweils für den Besitzer (UID), die Gruppe (GID) und alle anderen Lese-, Schreib-, und Ausführungsberechtigungen. Die Entscheidung, ob eine Anwendung auf eine Datei oder ein Verzeichnis zugreifen darf, trifft das Betriebssystem auf Basis der Benutzeridentität. Listing 2 zeigt das Datenverzeichnis der Android-Applikationen "Twitter" inklusive Zugriffsberechtigungen.
root@android # ls -R -l /data/data/com.twitter.android
.:
drwxr-xr-x app_65 app_65 2011-08-08 17:01 com.twitter.android
/data/data/com.twitter.android:
drwxrwx--x app_65 app_65 2011-08-08 17:01 shared_prefs
drwxrwx--x app_65 app_65 2011-08-08 17:01 databases
drwxr-xr-x system system 2011-08-08 17:01 lib
/data/data/com.twitter.android/shared_prefs:
-rw-rw---- app_65 app_65 173 2011-08-08 17:04 HomeTabActivity.xml
-rw-rw---- app_65 app_65 154 2011-08-08 17:04 TimelineActivity.xml
-rw-rw---- app_65 app_65 388 2011-08-08 17:04 com.twitter.android_preferences.xml
-rw-rw---- app_65 app_65 113 2011-08-08 17:02 search_prefs.xml
/data/data/com.twitter.android/databases:
-rw-rw---- app_65 app_65 35840 2011-08-08 17:04 236877107.db
-rw-rw---- app_65 app_65 14336 2011-08-08 17:04 global.db
-rw-rw---- app_65 app_65 37888 2011-08-08 17:02 0.db
Listing 2: Zugriffsberechtigungen auf das Datenverzeichnis einer Applikation
Da das Betriebssystem jede Applikation unter einer eindeutigen Benutzeridentität ausführt, ist der Zugriff auf Daten anderer Applikationen nur möglich, wenn Leseberechtigungen für "alle" gesetzt sind. Diese Leseberechtigung können Entwickler beim Anlegen einer Datei auf dem internen Speicher durch explizites Setzen des Flags MODE_WORLD_READABLE angeben (Listing 3). Sollen Daten nur der eigenen Applikation zugänglich sein, muss man beim Speichern das Flag MODE_PRIVATE setzen.
FileOutputStream fos = openFileOutput(FILENAME, Context.MODE_WORLD_READABLE);
fos.write(string.getBytes());
fos.close();
Listing 3: Setzen der Zugriffsberechtigung beim Anlegen einer Datei
Eine Ausnahme bilden Applikationen, denen der Paketmanager bei der Installation dieselbe Benutzeridentität zugewiesen hat. Dies ist möglich, wenn Applikationen dieselbe Signatur aufweisen - d.h. wenn Sie vom selben Entwickler stammen. Derartige Applikationen besitzen eine sogenannte SharedUserId (vgl. Listing 1). Mit derselben Benutzeridentität ausgestattet, können die Applikationen gegenseitig auf die lokal gespeicherten Daten zugreifen.
Spezialfall SD-Karten
Eine weitere Besonderheit unter Android bilden externe Speichermedien wie beispielsweise SD-Karten. Legen Applikationen Daten auf einem externen Speichermedium ab, sind diese für alle Applikationen lesbar. Ursache hierfür ist das File Allocation Table (FAT) Dateisystem, mit dem die externen Datenträger in der Regel formatiert sind. Die Berechtigungen für diesen Datenspeicher legt das Betriebssystem mit Hilfe von Mount-Optionen beim Einbinden des Datenträgers global fest. Listing 4 zeigt die Ausgabe von mount auf einem Android-Gerät. Die Mount-Optionen fmask und dmask bestimmen dabei die Zugriffsrechte für alle Dateien und Verzeichnisse der SD-Karte. Standardmäßig sind diese so konfiguriert, dass alle Applikationen Zugriff auf die gespeicherten Daten der SD-Karte haben. Mitglieder der Gruppe sdcard_rw können zudem alle Daten des externen Datenträgers verändern (Listing 4).
root@android # mount
/dev/block//vold/179:1 /sdcard vfat rw,dirsync,nosuid,nodev,noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
# ls /sdcard
d---rwxr-x system sdcard_rw 2011-04-08 13:22 LOST.DIR
d---rwxr-x system sdcard_rw 2011-04-21 10:42 DCIM
d---rwxr-x system sdcard_rw 2011-07-13 13:49 Android
d---rwxr-x system sdcard_rw 2011-07-19 16:26 download
----rwxr-x system sdcard_rw 302325 2011-05-16 17:01 GingerBreak-v1.20.apk
Listing 4: Zugriffsberechtigungen von externen Speichermedien
Applikationen wollen aber nicht nur Daten lokal auf einem Gerät ablegen, sondern häufig auch auf Ressourcen wie beispielsweise das Netzwerk zugreifen oder Informationen mit anderen Applikationen austauschen. Mit dem Konzept der Content Provider stellt Android eine elegante Lösung für den Datenaustausch bereit. Content Provider erlauben eine Zugriffskontrolle anhand eines granularen Rechtemodells, den sogenannten Android-Permissions. Mit Hilfe von Android-Permissions deklariert ein Entwickler, welche Berechtigungen seine Applikationen zum Durchführen ihrer Aktionen benötigt. Dem Entwickler steht hierfür eine Reihe an Standardberechtigungen zur Verfügung. Beispiel für eine Zugriffsberechtigung auf einen von Android ausgelieferten Content Provider ist die Berechtigung READ_CONTACTS. Diese erlaubt einer Anwendung den Zugriff auf das Adressbuch des Benutzers. Weitere Beispiele für Standardberechtigungen sind der Zugriff auf die Telefonfunktion (CALL_PHONE) oder die Verwendung des Netzwerks (INTERNET). Die erforderlichen Berechtigungen einer Anwendung gibt der Entwickler im Manifest der Applikation an (Listing 5).
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android=http://schemas.android.com/apk/res/android
package="de.cirosec" android:versionCode="1" android:versionName="1.0">
<application android:icon="@drawable/icon" android:label="@string/app_name">
<activity android:name="de.cirosec.Cirosec" android:label="@string/app_name"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
<intent-filter>
</activity>
</application>
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.WAKE_LOCK" /><uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
</manifest>
Listing 5: Manifest einer Android-Applikation
Verschiedene Schutzstufen
Die einzelnen Berechtigungen untergliedert Android in verschiedene Schutzstufen. Zur niedrigsten Schutzstufe "normal" gehört beispielsweise die Berechtigung VIBRATE, die einer Applikation den Zugriff auf den Vibrationsalarm ermöglicht. In der Berechtigungsstufe "dangerous" finden sich alle Berechtigungen mit Zugriff auf persönliche Daten des Benutzers (bspw. READ_SMS) oder zur Steuerung des Gerätes (bspw. WRITE_SETTINGS). Darüber hinaus gibt es noch die Schutzklassen "signature" und "signatureOrSystem", die Interaktionen (bspw. INJECT_EVENTS) zwischen Applikationen mit gleicher Signatur oder Änderungen am System (bspw. INSTALL_PACKAGES) durch Applikationen des Herstellers reglementieren. Welche Schutzklasse einer Berechtigung zugeteilt ist, kann man im Source Code von Android nachlesen. Listing 6 zeigt einen Auszug aus der entsprechenden Quelltextdatei AndroidManifest.xml.
<!-- + /* //device/apps/common/AndroidManifest.xml
...
<!-- ================================== -->
<!-- Permissions for accessing messages -->
<!-- ================================== -->+...
<!-- Allows an application to monitor incoming SMS messages, to record or perform processing on them. -->
<permission android:name="android.permission.RECEIVE_SMS"android:permissionGroup="android.permission-group.MESSAGES" android:protectionLevel="dangerous" android:label="@string/permlab_receiveSms" android:description="@string/permdesc_receiveSms"/>
...
Listing 6: Android-Berechtigungen und zugehörige Schutzklasse
Ressourcenzugriffe der Schutzklasse "dangerous" präsentiert der Paketmanager dem Benutzer bei der Installation einer Applikation und verlangt die Bestätigung aller angeforderten Berechtigungen.
Foto: Ronny Sackmann
Den Zugriff auf eine Ressource steuert Android über die Mitgliedschaft in Benutzergruppen. Bestätigt ein Anwender bei der Installation einer Anwendung die angeforderten Berechtigungen, fügt der Paketmanager die Applikation jeweils der zu einer Berechtigung zugehörigen Benutzergruppe hinzu. Die Zuordnung zwischen Benutzergruppe und Berechtigungen speichert Android in der Datei /system/etc/permissions/platform.xml (Listing 7).
<!-- /system/etc/permissions/platform.xml -->
<permissions>
...
<permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
<group gid="sdcard_rw" />
</permission>+
<permission name="android.permission.INTERNET" >
<group gid="inet" />
</permission>
...
</permissions>
Listing 7: Android-Berechtigungen und zugehörige Benutzergruppe
Die Anwendung "Twitter" fordert beispielsweise die Berechtigung für den Zugriff auf die Speicherkarte (WRITE_EXTERNAL_STORAGE). Der Paketmanager fügt die Applikationen daraufhin bei der Installation der zugehörigen Benutzergruppe sdcard_rw hinzu. Die Kontrolle der Zugriffsberechtigungen erledigt der Betriebssystemkern anhand der Gruppenzugehörigkeit, wofür teilweise Kernelanpassungen notwendig waren]
Im Gegensatz zu seinen Konkurrenten unterstützt die mobile Plattform von Google Multitasking und erlaubt das gleichzeitige Ausführen von Applikationen. Damit einher geht eine Kommunikation der Applikationen untereinander. Um dabei die Sicherheit des Systems aufrecht zu erhalten, hat Google das unter Linux für die Interprozess-Kommunikation (IPC) eingesetzte System-V-IPC durch OpenBinder ersetzt. OpenBinder erlaubt die Prüfung von Berechtigungen auf Basis der Prozess- bzw. Benutzeridentität und ermöglicht somit die Umsetzung des Android-Berechtigungsmodells auch auf IPC-Ebene.
Berechtigungsvergabe: Alles oder Nichts
Foto: Lamian
Das Sicherheitskonzept von Android kann einen guten Schutz gegen den Datendiebstahl durch schadhafte Applikationen bieten. Einschränkungen ergeben sich allerdings durch das Alles-oder-Nichts-Prinzip der Berechtigungsvergabe: Ein Anwender muss stets allen angeforderten Berechtigungen zustimmen. Es ist nicht möglich, einer Applikation den Zugriff auf das Netzwerk zu erlauben, den Zugriff auf die Kontakte aber zu verweigern. Abhilfe schaffen hier Drittprodukte wie "Privacy Guard" von Team LBE, das als Applikation im Android Market angeboten wird. Mit root-Rechten ausgestattet, kann LBE Privacy Guard die Ressourcenzugriffe anderer Applikationen mittels API-Interception abfangen und unterbinden. Eine weitere Alternative ist WhisperCore der Firma WhisperSystem. Bei WhisperCore handelt es sich um eine angepasste Android-Version mit speziellen Sicherheitsfeatures. Dazu gehören eine Geräteverschlüsselung, eine Firewall, verschlüsselte Datensicherungen und eine selektive Berechtigungsvergabe. WhisperCore befindet sich derzeit allerdings noch im Beta-Stadium und ist lediglich für das Nexus One und Nexus S verfügbar. Wichtige Voraussetzung für die Datensicherheit ist daher weiterhin ein mündiger Anwender, der bei der Installation von Applikationen nicht sorglos Berechtigungen vergibt, sondern vor der Zustimmung überlegt, ob das neu erworbene Rennspiel tatsächlich Zugriff auf die Kontakte, den Kalender, die SMS-Nachrichten, das Netzwerk und den aktuellen Standort benötigt.
Unter Android ist dies besonders brisant, da Google die im Downloadportal Android Market angebotenen Applikationen vor deren Veröffentlichung keiner ausgiebigen Prüfung unterzieht - wie dies bei Apple oder Microsoft der Fall ist. Vielmehr setzt Android auf die Mithilfe der Anwender zur Identifikation von schadhaften Applikationen. Gemeldete Anwendungen entfernt Google dann nachträglich aus dem Android Market und löscht die Applikationen von den betroffenen Geräten. Naturgemäß öffnet sich dadurch stets ein Zeitfenster, in dem Google schadhafte Applikationen im Android Market anbietet. Getarnt als "Super Ringtone Maker", "Scientific Calculator" oder "Super Guitar Solo" sind diese Applikationen für Anwender auf den ersten Blick nur sehr schwer als Malware zu identifizieren. Erst Anfang 2011 musste Google über 50 Applikationen aus seinem Android Market entfernen, die einen Schadcode zum Auslesen von Benutzerdaten enthielten. Im Sommer 2011 veröffentlichten Sicherheitsforscher auf der Sicherheitskonferenz BlackHat in Las Vegas die Ergebnisse einer durchgeführten Verhaltensanalyse von über 10 000 Applikationen des Android Markets. Erschreckendes Ergebnis: Acht Prozent der untersuchten Applikationen führen schadhafte Aktivitäten auf Geräten durch. Darüber hinaus können Anwender Applikationen auch aus alternativen Quellen installieren. Über solche Quellen verbreitete sich Ende des vergangenen Jahres ein Trojaner für das Android-Betriebssystem.
Ein weiteres Sicherheitsrisiko unter Android ist die derzeit auf vielen Geräten noch fehlende Geräteverschlüsselung und damit der mangelnde Schutz von lokal gespeicherten Daten. Diesen Umstand adressiert Google mit Android 3.0 "Honeycomb". Auf Basis von dm-crypt kann ein Anwender den internen Flash-Speicher mittels AES und einem 128-Bit Masterschlüssel verschlüsseln. Der Masterschlüssel wiederum wird mit einem Benutzerpasswort geschützt, dass der Anwender bei jedem Bootvorgang zum Entschlüsseln des Datenträgers angeben muss.
Foto: Samsung
Bisher ist die Geräteverschlüsselung aber nur für Tablet-Geräte mit Andoid 3.0 und ext4-Dateisystem verfügbar. Eine Ausnahme bildet das Samsung Galaxy S2, das bereits unter Android 2.3 eine Verschlüsselung von lokalen Daten ermöglicht. Die Geräteverschlüsselung bietet einen guten Schutz vor Datendiebstahl beim Verlust eines Gerätes. Zur Laufzeit stehen gespeicherte Daten allerdings im Klartext zur Verfügung. Schafft es eine Schadsoftware den Sandboxmechanismus auszuhebeln oder hat ein Benutzer die Applikation mit administrativen Rechten ausgestattet, kann sie trotz Geräteverschlüsselung alle lokal gespeicherten Daten auslesen. Applikationen sollten sicherheitsrelevante oder benutzerbezogene Daten daher stets zusätzlich auf Dateiebene verschlüsselt ablegen. Zur Verschlüsselung von Daten auf Dateiebene steht Entwicklern beispielsweise die Java-Klasse Cipher zur Verfügung.
Hardwareseitiger Schutz
Ein weiterer Bestandteil der Sicherheitsarchitektur von Android ist ein hardwareseitiger Schutz, um die Ausnutzung von Softwareschwachstellen zu erschweren. Mit Hilfe des sogenannten eXecute-Never Bit (XN Bit) des ARM-Prozessors markiert das Betriebssystem seit Android 2.3 auf unterstützten Geräten wie dem Nexus S bestimmte Speicherbereiche wie Stack und Heap hardwareseitig als nicht ausführbar. Darüber hinaus stellt das XN Bit sicher, dass keine Speicherseiten gleichzeitig Berechtigungen zum Lesen, Schreiben und Ausführen besitzen. Dies bietet einen wirksamen Schutz gegen Code Injection und verhindert das Einschleusen von Programmcode.
Unter Zuhilfenahme der "Return Oriented Programming"-Technik (ROP) ist die Ausnutzung von Softwareschwachstellen aber dennoch möglich. Bei dieser Technik wird nicht versucht, eigenen Programmcode in den Speicher einzuschleusen, sondern auf die bereits im Speicher vorhandenen Instruktionen zurückzugreifen und aus diesen den Exploit-Code zusammenzustellen. Um die vorhandenen Instruktionen anspringen zu können, muss ein Schadcode allerdings deren Speicheradressen kennen. Linux erschwert die die Vorhersage von Speicheradressen seit Kernel durch eine Speicherverwürfelung (Address Space Layout Randomization, ASLR). Bei dieser Technik vergibt der Kernel beim Laden eines Prozesses die Adressbereiche von Bibliotheken und Programmen im Speicher zufällig, wodurch ein Schadcode die Speicheradressen der erforderlichen Instruktionen nicht mehr vorhersagen kann. Wie die Ausgabe von sysctl -a in Listing 8 zeigt, ist ASLR auch unter Android augenscheinlich aktiviert.
root@android # sysctl -a
...
kernel.ngroups_max = 65536
kernel.randomize_va_space = 1
kernel.max_lock_depth = 1024
...
Listing 8: ASLR unter Android
Android nutzt allerdings kein vollständiges ASLR (kernel.randomize_va_space = 1), sondern die konservative Methode ohne eine zufällige Adressvergabe für den dynamischen Speicher (Heap). Darüber hinaus startet Android wie oben beschrieben alle Applikationen aus Effizienzgründen als Fork von Zygote und vererbt ihnen dessen Speicherlayout. Aus Performance-Gründen verwendet Android zudem in der Regel Bibliotheken mit fest codierten Speicheradressen. In Kombination mit weiteren Limitierungen der Plattform kann ein Angreifer die Speicherverwürfelung von Android daher zuverlässig aushebeln.
Für einen erfolgreichen Datendiebstahl ist es für einen Angreifer aber gar nicht notwendig Softwareschwachstellen auszunutzen. Vielmehr programmiert er eine augenscheinlich interessante Applikationen und stellt diese im Android Market zum Download bereit. Begleitet mit der Aufforderung, vorher den root-Account freizuschalten. Schließlich macht ein Besitzer sein Gerät damit noch leistungsfähiger und kann es nach Belieben modifizieren. Da es sich dabei im Wesentlichen um die Freischaltung des root-Zugangs handelt, wird dieser Vorgang unter Android als Rooting bezeichnet. Erstaunlicherweise gibt es im Android Market zahlreiche Applikationen, die im Kontext des root-Benutzers ausgeführt werden wollen. Hat ein Anwender sein Android-Gerät "gerootet" und installiert auf diesem Applikationen mit root-Berechtigungen, haben diese die volle Kontrolle über das System. Die Möglichkeiten für schadhafte Applikationen reichen vom Diebstahl der gespeicherten Daten über das Mitschneiden von Eingaben auf der virtuellen Tastatur bis hin zum Missbrauch als Wanze.
Dies erweist sich insbesondere im Unternehmensumfeld als Herausforderung, da ein Anwender durch das Rooting das Sicherheitsmodell von Android unterwandert und die gespeicherten Unternehmensdaten einem höheren Risiko aussetzt. Administratoren können "gerootete" Geräte teilweise über Mobile Device Management Produkte wie Sybase Afaria detektieren und entsprechende Maßnahmen einleiten. Dazu gehört beispielsweise die Benachrichtigung des Benutzers oder die Sperrung des Zugangs zum Firmennetz.
Die für eine zentrale Verwaltung erforderliche "Device Administration"-Schnittstelle stellt Android seit der Betriebssystemversion 2.2 zur Verfügung. Diese Schnittstelle erlaubt es Administratoren, Sicherheitsrichtlinien von zentraler Stelle aus umzusetzen. Die Konfigurationseinstellungen sind derzeit allerdings im Wesentlichen auf die Umsetzung von Passwortrichtlinien für den Zugriffsschutz begrenzt. Bei einem Verlust der Geräte können Administratoren alle gespeicherten Benutzerdaten löschen und die Geräte in den Werkszustand zurücksetzen. Hersteller von Mobile Device Management Lösungen bieten darüber hinaus die Möglichkeit, Informationen wie beispielsweise die aktuelle Betriebssystemversion oder eine Liste der installierten Anwendungen von den Android-Geräten abzufragen.
Eine weitere Herausforderung für Administratoren stellt die starke Fragmentierung dar. Zum einen im Hinblick auf die Bereitstellung von Betriebssystemaktualisierungen zum anderen aber auch im Zusammenhang mit der zentralen Verwaltung der Android-Geräte. Letzteres wird erst seit Version 2.2 unterstützt, die derzeit auf vielen Geräten noch nicht verfügbar ist. Dies wiederum ist dem langwierigen Update-Prozess der Hersteller geschuldet. Auch in Zukunft wird es Erweiterungen geben, die nur auf der aktuellsten Betriebssystemversion verfügbar sind. Kleiner Trost ist die bei den meisten Geräten verfügbare, automatische Systemaktualisierung über die Luftschnittstelle (OTA), die nach Bestätigung der Anwender direkt auf dem Android-Gerät durchgeführt wird. Unternehmen sind dennoch gut beraten, auf einen oder wenige Hersteller zu setzen und vorher in Erfahrung zu bringen, ob und in welcher Häufigkeit dieser Aktualisierungen bereitstellen wird.
Fazit
Insgesamt überzeugt Android mit einem durchdachten Sicherheitskonzept, das geschickt die Vorteile der etablierten Sicherheitsmechanismen von Linux mit neuen Sicherheitsfunktionen kombiniert. Insbesondere das Sandboxing der einzelnen Applikationen und das Konzept der Android Berechtigungen können einen guten Schutz gegen Datendiebstahl bieten.
Einschränkungen ergeben sich allerdings durch das Alles-oder-Nichts-Prinzip der Berechtigungsvergabe. Dies kommt insbesondere zum Tragen, weil Applikationen vor deren Veröffentlichung im Android Market nicht von Google kontrolliert werden. Mit steigender Popularität des Google-Betriebssystems weckt der Android Market das Interesse von Kriminellen und wird zunehmend auch als Distributionskanal von Malware missbraucht. Eine selektive Berechtigungsvergabe wäre hier wünschenswert, um den Datendiebstahl durch Applikationen einzudämmen. Nach dem BlackBerry-Vorbild am besten auch über die Administrationsschnittstelle von zentraler Stelle aus.
Man muss Android allerdings zugutehalten, dass es sich noch um ein relativ junges Betriebssystem handelt und Google stetig an der Verbesserung seiner Plattform arbeitet. In den jüngsten Android-Versionen hat Google mit ASLR und DEP sowie einer Geräteverschlüsselung nachgebessert. Mit Einführung der Administrationsschnittstelle in Android 2.2 hat Google zudem einen ersten Schritt in Richtung zentraler Verwaltung unternommen und die Basis für einen zukünftigen Einsatz im Unternehmensumfeld geschaffen. (mb)