App Sandbox in der mobilen Entwicklung — was es ist, Mechanismus und Funktionsprinzip

Was ist App Sandbox?

App Sandbox ist ein architektonischer Sicherheitsmechanismus, der jede Anwendung in ihrer eigenen Ausführungsumgebung mit eingeschränktem Zugriff auf Systemressourcen isoliert. Der Begriff stammt vom Konzept des Sandkastens für Kinder — einem sicheren Ort, an dem ein Kind spielen kann, ohne auf gefährliche Gegenstände zuzugreifen. Ähnlich läuft eine Anwendung in einer eingeschränkten Umgebung ohne Zugriff auf die Daten anderer Anwendungen oder kritischer Systemkomponenten.

Das Hauptziel von Sandbox ist die Umsetzung des Prinzips der geringsten Privilegien: jede Anwendung erhält nur die Rechte, die zur Ausführung ihrer erklärten Funktionen erforderlich sind. Selbst wenn ein Angreifer eine Schwachstelle in einer Anwendung findet, verhindert die Sandbox den Zugriff auf Daten anderer Anwendungen, Fotos, Kontakte oder Systemdateien. Der Schaden ist auf die Grenzen einer einzelnen Anwendung beschränkt.

Mobile Betriebssysteme haben Sandboxen früher implementiert als Desktop-Systeme. iOS verwendet Sandbox seit der ersten SDK-Veröffentlichung (2008), Android seit Version 1.0 (2008), mit Verstärkung in Android 4.3 (2013) durch SELinux. Desktop-Systeme holen auf: macOS führte Sandbox 2012 ein, Windows führte isolierte UWP-Anwendungen in Windows 8 ein.

Wie funktioniert die Isolierung in der Sandbox?

Die Isolierung in der Sandbox wird durch eine Kombination mehrerer Mechanismen auf verschiedenen Ebenen des Betriebssystems erreicht. Auf der Dateisystem-Ebene erhält jede Anwendung ein eigenes geschütztes Verzeichnis, auf das nur sie vollen Zugriff hat. Auf Prozessebene wird eine eindeutige Benutzerkennung (UID) für jede Anwendung verwendet. Auf Kernelebene wird eine obligatorische Zugriffskontrolle (MAC) durch SELinux oder ähnliche Mechanismen angewendet.

Dateisystem-Isolierung

Jede Anwendung erhält ein eigenes Stammverzeichnis auf dem Dateisystem des Geräts. In iOS ist dies das Verzeichnis /var/mobile/Containers/Data/Application/{UUID}, in Android — /data/data/{package_name}. Die Anwendung kann nur innerhalb dieses Verzeichnisses Dateien lesen und schreiben. Zugriff auf Dateien außerhalb dieses Verzeichnisses wird auf Kernelebene des Betriebssystems blockiert.

Das System stellt auch spezielle gemeinsame Verzeichnisse mit eingeschränktem Zugriff bereit. In iOS sind dies das Documents-Verzeichnis für Benutzerdaten, Library für Einstellungen und Caches für temporäre Dateien. In Android — interner Speicher (getFilesDir) und externer Speicher (getExternalFilesDir), deren Zugriff keine zusätzlichen Berechtigungen erfordert.

Prozess- und UID-Isolierung

In Android läuft jede Anwendung als separater Linux-Prozess mit einer eindeutigen UID (Benutzer-ID). Die UID wird bei der Installation der Anwendung zugewiesen und bleibt während des gesamten Lebenszyklus unverändert. Prozesse mit unterschiedlichen UIDs sind auf Kernelebene voneinander isoliert — sie können nicht auf den Speicher oder die Dateien des anderen zugreifen. Ein ähnlicher Mechanismus funktioniert in iOS über den XNU-Kernel und sein Schutzsystem.

Eine zusätzliche Schutzschicht in Android wird durch SELinux (Security-Enhanced Linux) im Enforcing-Modus seit Android 4.3 bereitgestellt. SELinux implementiert eine obligatorische Zugriffskontrolle (MAC): jede Prozessaktion wird unabhängig von den Berechtigungen des Dateibesitzers gegen die Sicherheitsrichtlinie geprüft. Selbst wenn eine Anwendung mit UID root läuft, kann SELinux den Zugriff auf bestimmte Ressourcen blockieren.

Sandbox in iOS

Die iOS-Sandbox gilt als eine der strengsten unter den mobilen Betriebssystemen. Jede Anwendung ist auf Container-Ebene isoliert — einem geschützten Bereich des Dateisystems, auf den andere Anwendungen nicht zugreifen können. iOS verwendet eine Kombination aus obligatorischer Zugriffskontrolle über die Sandbox Kernel Extension (Sandbox.kext) und dem Entitlement-Mechanismus zur Gewährung erweiterter Privilegien.

iOS-Containerstruktur

Der iOS-Anwendungscontainer besteht aus mehreren Verzeichnissen mit unterschiedlichen Zugriffsebenen. Documents — für Benutzerdaten, die bei der Sicherung über iCloud und iTunes erhalten bleiben. Library — für Konfigurations- und Cache-Dateien. tmp — für temporäre Daten, die das System jederzeit löschen kann. AppName.app — das Anwendungsbundle selbst, das schreibgeschützt ist.

Der Zugriff auf Daten anderer Anwendungen ist strengstens untersagt. iOS stellt keine API zum Lesen von Dateien aus dem Container einer anderen Anwendung bereit. Die einzige Möglichkeit, Daten auszutauschen, sind Systemmechanismen: UIActivityViewController zum Teilen, UIPasteboard für die Zwischenablage, App Groups für Anwendungen desselben Entwicklers. Jeder dieser Mechanismen arbeitet unter der Kontrolle des Betriebssystems.

Entitlements und App Sandbox in iOS

Erweiterte Funktionen über die Standardsandbox hinaus werden durch Entitlements bereitgestellt — digitale Signaturen, die der Codesignatur der Anwendung hinzugefügt werden. Beispielsweise ermöglicht das Entitlement com.apple.security.application-groups Anwendungen derselben Gruppe einen gemeinsam genutzten Container. Push-Benachrichtigungen, iCloud, Apple Pay — all diese Funktionen erfordern entsprechende Entitlements.

Es ist wichtig zu beachten, dass Entitlements in iOS nicht dasselbe wie Berechtigungen sind. Berechtigungen werden zur Laufzeit vom Benutzer angefordert (z.B. Kamerazugriff), während Entitlements vom System bei der Installation überprüft werden und vom Benutzer nicht geändert werden können. Entitlements werden vom Entwickler definiert und während des App-Überprüfungsprozesses von Apple signiert.

Sandbox in Android

Android verwendet ein mehrschichtiges Sandbox-Modell basierend auf dem Linux-Kernel. Jede Anwendung läuft als separater Linux-Benutzer mit einer eindeutigen UID, was eine grundlegende Isolierung auf Prozess- und Dateiebene bietet. Zusätzliche Schichten umfassen SELinux für die obligatorische Zugriffskontrolle und Berechtigungen zur Steuerung des Zugriffs auf System-APIs.

SELinux und UID-Isolierung

SELinux in Android läuft im Enforcing-Modus, was die erzwungene Anwendung von Sicherheitsrichtlinien bedeutet. Jeder Anwendung wird ein Sicherheitskontext zugewiesen, und alle Systemaufrufe werden gegen die Richtlinie geprüft. SELinux in Android enthält über 1500 Regeln, die das Dateisystem, die Interprozesskommunikation, Sockets und Systemaufrufe abdecken.

Die UID-Isolierung verhindert den direkten Zugriff einer Anwendung auf die Dateien einer anderen Anwendung. Beispielsweise kann Anwendung A mit UID 10001 keine Dateien von Anwendung B mit UID 10002 lesen, selbst wenn beide unter demselben Telefonbenutzerkonto ausgeführt werden. Dies ist das Grundprinzip der Multiuser-Sicherheit von Linux, angepasst für mobile Geräte.

// Zugriff auf das eigene Anwendungsverzeichnis in Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// Der Zugriffsversuch auf ein fremdes Verzeichnis löst SecurityException aus
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// Verwendung von FileProvider für sicheres Dateiteilen
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Android bietet zusätzliche Mechanismen für den sicheren Datenaustausch zwischen Anwendungen. ContentProvider — eine Android-Komponente, die es einer Anwendung ermöglicht, anderen Anwendungen über eine streng definierte URI Zugriff auf ihre Daten zu gewähren. FileProvider — eine sichere Möglichkeit, Dateien zu teilen, ohne Dateisystempfade preiszugeben.

Einschränkungen und Sicherheit der Sandbox

Obwohl App Sandbox ein leistungsstarker Sicherheitsmechanismus ist, hat er grundlegende Einschränkungen. Die Sandbox schützt vor horizontalem Zugriff (Anwendung-zu-Anwendung), aber nicht vor vertikalem Zugriff (Malware auf Kernelebene oder physischer Zugriff auf das Gerät). Bei Jailbreak oder Root-Zugriff kann die Sandbox umgangen werden, da der Angreifer Superuser-Privilegien erhält.

Die zweite Einschränkung sind bösartige Berechtigungen. Wenn ein Benutzer einer Anwendung Zugriff auf Kontakte und Mikrofon gewährt, kann die Sandbox die Erfassung dieser Daten nicht verhindern, da die Anwendung legitime System-APIs verwendet. Der Schutz geht in diesem Fall auf die Ebene des Benutzerbewusstseins und der Überprüfungsprozesse von App Store und Google Play über.

Die dritte Einschränkung ist die Interaktion zwischen Sandboxes. Einige Systemdienste (NotificationListenerService, AccessibilityService) haben erweiterten Zugriff auf die Daten anderer Anwendungen. Ein Angreifer könnte diese Dienste nutzen, um die Sandbox zu umgehen, wenn er die entsprechenden Berechtigungen erhält. Google und Apple aktualisieren ständig die Richtlinien für solche Dienste.

Trotz der Einschränkungen ist die Sandbox ein kritischer Sicherheitsbestandteil mobiler Betriebssysteme. Laut Android Security Report (2024) verhindert die Sandbox-Isolierung mehr als 99% der Zugriffsversuche zwischen Anwendungen. In Kombination mit Code-Signing, App Review und Laufzeitberechtigungen bildet Sandbox einen mehrschichtigen Schutz moderner mobiler Geräte.