Anwendungs-Sandbox

Die Android-Plattform nutzt den nutzerbasierten Schutz von Linux, um App-Ressourcen zu identifizieren und zu isolieren. Dadurch werden Apps voneinander isoliert und Apps und das System vor schädlichen Apps geschützt. Dazu weist Android jeder Android-App eine eindeutige Nutzer-ID (UID) zu und führt sie in einem eigenen Prozess aus.

Android verwendet die UID, um eine Anwendungs-Sandbox auf Kernelebene einzurichten. Der Kernel erzwingt die Sicherheit zwischen Apps und dem System auf Prozessebene über standardmäßige Linux-Funktionen wie Nutzer- und Gruppen-IDs, die Apps zugewiesen werden. Standardmäßig können Apps nicht miteinander interagieren und haben nur eingeschränkten Zugriff auf das Betriebssystem. Wenn App A versucht, etwas Böswilliges zu tun, z. B. die Daten von App B zu lesen oder ohne Erlaubnis eine Telefonnummer anzurufen, wird dies verhindert, da App A nicht die entsprechenden Standardnutzerberechtigungen hat. Die Sandbox ist einfach, überprüfbar und basiert auf der jahrzehntealten UNIX-Nutzertrennung von Prozessen und Dateiberechtigungen.

Da sich die Anwendungs-Sandbox im Kernel befindet, erstreckt sich dieses Sicherheitsmodell sowohl auf nativen Code als auch auf Betriebssystem-Apps. Alle Software über dem Kernel, z. B. Betriebssystembibliotheken, App-Framework, App-Laufzeit und alle Apps, werden in der Anwendungs-Sandbox ausgeführt. Auf einigen Plattformen sind Entwickler auf ein bestimmtes Entwicklungsframework, eine bestimmte API oder eine bestimmte Sprache beschränkt. Unter Android gibt es keine Einschränkungen für die Erstellung einer App, die für die Durchsetzung der Sicherheit erforderlich sind. In dieser Hinsicht wird nativer Code genauso wie interpretierter Code in einer Sandbox ausgeführt.

Schutzmaßnahmen

Im Allgemeinen muss die Sicherheit des Linux-Kernels beeinträchtigt werden, um auf einem ordnungsgemäß konfigurierten Gerät aus der Anwendungs-Sandbox auszubrechen. Ähnlich wie bei anderen Sicherheitsfunktionen sind auch die einzelnen Schutzmaßnahmen, die die App-Sandbox erzwingen, nicht unverwundbar. Daher ist eine mehrschichtige Verteidigung wichtig, um zu verhindern, dass einzelne Sicherheitslücken zum Verhacken des Betriebssystems oder anderer Apps führen.

Android setzt eine Reihe von Schutzmaßnahmen ein, um die App-Sandbox durchzusetzen. Diese Maßnahmen wurden im Laufe der Zeit eingeführt und haben die ursprüngliche UID-basierte Sandbox für die benutzerdefinierte Zugriffssteuerung (Discretionary Access Control, DAC) erheblich gestärkt. Frühere Android-Releases enthielten die folgenden Schutzmaßnahmen:

  • In Android 5.0 sorgte SELinux für eine MAC-Trennung (Mandatory Access Control) zwischen System und Apps. Alle Drittanbieter-Apps wurden jedoch im selben SELinux-Kontext ausgeführt, sodass die App-übergreifende Isolation hauptsächlich durch UID DAC erzwungen wurde.
  • In Android 6.0 wurde die SELinux-Sandbox erweitert, um Apps über die Grenze des einzelnen Nutzers hinweg zu isolieren. Außerdem hat Android sicherere Standardeinstellungen für App-Daten festgelegt: Bei Apps mit targetSdkVersion >= 24 wurden die standardmäßigen DAC-Berechtigungen für das Basisverzeichnis einer App von 751 auf 700 geändert. Dies sorgte für eine sicherere Standardeinstellung für private App-Daten, die jedoch von Apps überschrieben werden kann.
  • Unter Android 8.0 wurden alle Apps so konfiguriert, dass sie mit einem seccomp-bpf-Filter ausgeführt wurden, der die von Apps zulässigen Systemaufrufe einschränkte. Dadurch wurde die Grenze zwischen App und Kernel verstärkt.
  • Unter Android 9 müssen alle nicht privilegierten Apps mit targetSdkVersion >= 28 in einzelnen SELinux-Sandboxes ausgeführt werden, um MAC auf App-Basis bereitzustellen. Dieser Schutz verbessert die App-Trennung, verhindert das Überschreiben sicherer Standardeinstellungen und – was am wichtigsten ist – verhindert, dass Apps ihre Daten weltweit zugänglich machen.
  • Unter Android 10 haben Apps nur eine eingeschränkte Rohansicht des Dateisystems und keinen direkten Zugriff auf Pfade wie /sdcard/DCIM. Apps behalten jedoch den vollständigen Rohzugriff auf ihre paketspezifischen Pfade, die von allen anwendbaren Methoden wie Context.getExternalFilesDir() zurückgegeben werden.

Richtlinien für die Freigabe von Dateien

Es ist nicht empfehlenswert, App-Daten für alle zugänglich zu machen. Der Zugriff wird allen gewährt und es ist nicht möglich, den Zugriff auf die beabsichtigten Empfänger zu beschränken. Diese Praxis hat zu Datenlecks und Verwirrung bei den Deputiertenlücken geführt und ist ein beliebtes Ziel für Malware, die auf Apps mit sensiblen Daten abzielt (z. B. E-Mail-Clients). Unter Android 9 und höher ist das Teilen von Dateien auf diese Weise für Apps mit targetSdkVersion>=28 ausdrücklich nicht zulässig.

Anstatt App-Daten für alle zugänglich zu machen, sollten Sie beim Freigeben von Dateien die folgenden Richtlinien beachten:

  • Wenn Ihre App Dateien mit einer anderen App teilen muss, verwenden Sie einen Inhaltsanbieter. Contentanbieter geben Daten mit der richtigen Detailgenauigkeit und ohne die vielen Nachteile von weltweit zugänglichen UNIX-Berechtigungen weiter. Weitere Informationen finden Sie unter Grundlagen für Contentanbieter.
  • Wenn Ihre App Dateien enthält, die für alle Nutzer zugänglich sein sollen (z. B. Fotos), müssen sie medienspezifisch sein (nur Fotos, Videos und Audiodateien) und mit der Klasse MediaStore gespeichert werden. Weitere Informationen zum Hinzufügen eines Medienelements finden Sie unter Zugriff auf Mediendateien aus freigegebenem Speicher.

Die Laufzeitberechtigung Speicher steuert den Zugriff auf stark typisierte Sammlungen über MediaStore. Für den Zugriff auf schwach typisierte Dateien wie PDFs und die Klasse MediaStore.Downloads müssen Apps Intents wie den ACTION_OPEN_DOCUMENT-Intent verwenden.

Wenn Sie das Verhalten von Android 10 aktivieren möchten, verwenden Sie das Manifestattribut requestLegacyExternalStorage und beachten Sie die Best Practices für App-Berechtigungen.

  • Der Standardwert für das Manifest-Flag ist true für Apps, die auf Android 9 (und niedriger) ausgerichtet sind.
  • Der Standardwert ist „false“ für Apps, die auf Android 10 ausgerichtet sind. Wenn Sie die gefilterte Speicheransicht in Apps, die auf Android 10 ausgerichtet sind, vorübergehend deaktivieren möchten, legen Sie den Wert des Manifest-Flags auf true fest.
  • Mit eingeschränkten Berechtigungen setzt das Installationsprogramm eine Zulassungsliste für Apps auf, die für Speicher außerhalb der Sandbox zulässig sind. Apps, die nicht auf der Zulassungsliste stehen, werden in einer Sandbox ausgeführt.