PDF 941kB - Hochschule Ulm

Smartphone Betriebssysteme
operiert, wie unter Windows und Windows Server. Im LPC werden die Capabilities dynamisch,
abhängig von App und Herausgeber, verteilt. Dabei werden die Capabilities
in drei Gruppen unterteilt, wie auf Folie 8 in [EC13] gezeigt wird: Entwickler, Original-Equipment-Manufacturer
(OEM) und System. In der Gruppe System werden Capabilties
definiert, die unter Umständen sicherheitstechnisch bedenklich und deshalb nur
für Microsoft-Programmierer bestimmt sind. Betriebssystemkomponenten und Treiber
werden typischerweise von diesen Capabilities Gebrauch machen. OEMs werden ebenso
spezielle Capabilities bereitgestellt um Treiber als auch herstellerspezifische Apps
zu entwickeln. In der letzten Gruppe Entwickler befinden sich Capabilities, die häufig
verwendet werden von App-Entwicklern, die zugleich nicht die Sicherheit des Systems
beeinflussen können, um einen merkbaren Schaden anzurichten. In Abbildung 11 wird
das Sicherheitsmodell schematisch dargestellt.
Fixed-Rights-Chamber
Trusted Computing
Base
NT-Kernel
Dynamische Rechtevergabe
anhand von Capabilities
Least Priviliege
Chamber
Treiber,
Betriebssystemkomponenten,
Apps
...
Abbildung 11: TCB und LPC von Windows Phone 8.
Durch das Installieren einer App aus dem Windows Phone Store wird die WMApp-
Manifest.xml Datei vom Paket Manager daraufhin überprüft, welche Capabilities dort
definiert wurden. Anhand dieser Capabilities wird für die App ein neuer Chamber eingerichtet
mit nur den benötigten Rechten. Nachträglich lassen sich die Rechte eines
Chambers nicht ändern. Das typische Angriffsziel eines Angreifers wird die TCB sein.
Die Vergangenheit hat gezeigt, dass Fehler in OEM Treiber zur Privilege Escalation
(Rechteerhöhung) eines Angreifers führen kann, wie in [WP7] dokumentiert ist. Bedingt
dadurch, dass Treiber im LPC laufen und nur dem Treiber die nötigsten Rechte gegeben
werden, wird die Angriffsfläche auf den TCB deutlich reduziert. Wie oben erwähnt,
werden auch Betriebssystemkomponenten im LPC ausgeführt. Das Ziel, das sich Microsoft
gesetzt hat, ist so viele Komponenten wie möglich im LPC auszuführen um die
Angriffsfläche auf den TCB zu minimieren. Sollte z.B. eine System-App kompromittiert
werden, muss dies nicht zwangsweise weitreichende Folgen haben, da die App nur die
nötigsten Capabilities definiert hat, die die App auch benötigt. Des Weiteren müssen alle
Binärdateien von Microsoft digital signiert sein, um ausgeführt werden zu können. Dieses
sog. Code Signing (Codesignierung) verhindert das Modifizieren von z.B. Systemdateien
20