Anwendungs-Sandbox

Die Android-Plattform nutzt den benutzerbasierten Linux-Schutz, 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-Anwendung eine eindeutige Benutzer-ID (UID) zu und führt sie in einem eigenen Prozess aus.

Android verwendet die UID, um eine Anwendungs-Sandbox auf Kernel-Ebene einzurichten. Der Kernel erzwingt die Sicherheit zwischen Apps und dem System auf Prozessebene durch Standard-Linux-Funktionen wie Benutzer- 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ösartiges zu tun, beispielsweise die Daten von Anwendung B zu lesen oder ohne Erlaubnis das Telefon anzurufen, wird sie daran gehindert, da sie nicht über die entsprechenden Standardbenutzerrechte verfügt. Die Sandbox ist einfach, überprüfbar und basiert auf der jahrzehntealten Benutzertrennung von Prozessen und Dateiberechtigungen im UNIX-Stil.

Da sich die Anwendungssandbox im Kernel befindet, erstreckt sich dieses Sicherheitsmodell sowohl auf nativen Code als auch auf Betriebssystemanwendungen. Die gesamte Software über dem Kernel, z. B. Betriebssystembibliotheken, Anwendungsframework, Anwendungslaufzeit und alle Anwendungen, wird in der Anwendungssandbox ausgeführt. Auf einigen Plattformen sind Entwickler auf ein bestimmtes Entwicklungsframework, einen bestimmten API-Satz oder eine bestimmte Sprache beschränkt. Unter Android gibt es keine Einschränkungen hinsichtlich der Art und Weise, wie eine Anwendung geschrieben werden kann, die zur Durchsetzung der Sicherheit erforderlich sind. In dieser Hinsicht ist nativer Code genauso sandboxed wie interpretierter Code.

Schutzmaßnahmen

Um auf einem richtig konfigurierten Gerät aus der Anwendungssandbox auszubrechen, muss man im Allgemeinen die Sicherheit des Linux-Kernels gefährden. Allerdings sind, ähnlich wie bei anderen Sicherheitsfunktionen, individuelle Schutzmaßnahmen, die die Anwendungs-Sandbox durchsetzen, nicht unverwundbar. Daher ist eine Tiefenverteidigung wichtig, um zu verhindern, dass einzelne Schwachstellen zu einer Gefährdung des Betriebssystems oder anderer Apps führen.

Android ist auf eine Reihe von Schutzmaßnahmen angewiesen, um die Anwendungs-Sandbox durchzusetzen. Diese Durchsetzungsmaßnahmen wurden im Laufe der Zeit eingeführt und haben die ursprüngliche UID-basierte DAC-Sandbox (Discretionary Access Control) erheblich gestärkt. Frühere Android-Versionen enthielten die folgenden Schutzfunktionen:

  • In Android 5.0 sorgte SELinux für eine obligatorische MAC-Trennung (Access Control) zwischen dem System und den Apps. Da jedoch alle Apps von Drittanbietern im selben SELinux-Kontext ausgeführt wurden, wurde die Isolation zwischen Apps hauptsächlich durch UID DAC erzwungen.
  • In Android 6.0 wurde die SELinux-Sandbox erweitert, um Apps über die Grenze pro physischem Benutzer hinweg zu isolieren. Darüber hinaus hat Android auch sicherere Standardeinstellungen für Anwendungsdaten festgelegt: Für Apps mit targetSdkVersion >= 24 wurden die Standard-DAC-Berechtigungen für das Home-Verzeichnis einer App von 751 auf 700 geändert. Dadurch wurde eine sicherere Standardeinstellung für private App-Daten bereitgestellt (obwohl Apps diese Standardeinstellungen möglicherweise überschreiben). .
  • In Android 8.0 waren alle Apps so eingestellt, dass sie mit einem seccomp-bpf Filter ausgeführt wurden, der die Systemaufrufe einschränkte, die Apps verwenden durften, und so die App-/Kernel-Grenze stärkte.
  • In Android 9 müssen alle nicht privilegierten Apps mit targetSdkVersion >= 28 in einzelnen SELinux-Sandboxen ausgeführt werden, wobei MAC pro App bereitgestellt wird. Dieser Schutz verbessert die App-Trennung, verhindert das Überschreiben sicherer Standardeinstellungen und (was am wichtigsten ist) verhindert, dass Apps ihre Datenwelt zugänglich machen.
  • In Android 10 haben Apps 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, wie sie von allen anwendbaren Methoden wie Context.getExternalFilesDir() zurückgegeben werden.

Richtlinien zum Teilen von Dateien

Das Festlegen von App-Daten als weltweit zugänglich ist eine schlechte Sicherheitsmaßnahme. Der Zugriff wird jedem gewährt und es ist nicht möglich, den Zugriff nur auf die vorgesehenen Empfänger zu beschränken. Diese Praxis hat zu Informationslecks und unklaren Stellvertreter-Schwachstellen geführt und ist ein beliebtes Ziel für Malware, die es auf Apps mit sensiblen Daten (z. B. E-Mail-Clients) abgesehen hat. In Android 9 und höher ist das Teilen von Dateien auf diese Weise für Apps mit targetSdkVersion>=28 ausdrücklich verboten.

Anstatt App-Daten weltweit zugänglich zu machen, befolgen Sie beim Teilen von Dateien die folgenden Richtlinien:

  • Wenn Ihre App Dateien mit einer anderen App teilen muss, verwenden Sie einen Inhaltsanbieter . Inhaltsanbieter teilen Daten mit der richtigen Granularität und ohne die vielen Nachteile weltweit zugänglicher UNIX-Berechtigungen (Einzelheiten finden Sie unter Grundlagen von Inhaltsanbietern ).
  • Wenn Ihre App über Dateien verfügt, die wirklich für die Welt zugänglich sein sollten (z. B. Fotos), müssen diese medienspezifisch sein (nur Fotos, Videos und Audiodateien) und mithilfe der MediaStore- Klasse gespeichert werden. (Weitere Informationen zum Hinzufügen eines Medienelements finden Sie unter Auf Mediendateien aus dem freigegebenen Speicher zugreifen .)

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

Um das Android 10-Verhalten zu aktivieren, verwenden Sie das Manifestattribut requestLegacyExternalStorage “ und befolgen Sie die Best Practices für App-Berechtigungen .

  • Der Standardwert des Manifest-Flags 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. Um die gefilterte Speicheransicht in Apps, die auf Android 10 ausgerichtet sind, vorübergehend zu deaktivieren, legen Sie den Wert des Manifest-Flags auf true fest.
  • Mithilfe eingeschränkter Berechtigungen setzt das Installationsprogramm Apps auf die Whitelist, die für den Nicht-Sandbox-Speicher zugelassen sind. Nicht auf der Whitelist stehende Apps werden in einer Sandbox gespeichert.