Anwendungs-Sandbox

Die Android-Plattform nutzt den benutzerbasierten 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-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-Einrichtungen wie Benutzer- und Gruppen-IDs, die Apps zugewiesen werden. Standardmäßig können Apps nicht miteinander interagieren und haben eingeschränkten Zugriff auf das Betriebssystem. Wenn App A versucht, etwas Böswilliges zu tun, z. B. die Daten von Anwendung B zu lesen oder das Telefon ohne Erlaubnis 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 Anwendungs-Sandbox im Kernel befindet, erstreckt sich dieses Sicherheitsmodell sowohl auf nativen Code als auch auf Betriebssystemanwendungen. Die gesamte Software oberhalb des Kernels, wie z. B. Betriebssystembibliotheken, Anwendungsframework, Anwendungslaufzeit und alle Anwendungen, werden in der Anwendungs-Sandbox ausgeführt. Auf einigen Plattformen sind Entwickler auf ein bestimmtes Entwicklungsframework, einen Satz von APIs oder eine bestimmte Sprache beschränkt. Auf Android gibt es keine Einschränkungen, wie eine Anwendung geschrieben werden kann, die zur Durchsetzung der Sicherheit erforderlich sind; In dieser Hinsicht ist nativer Code so sandboxed wie interpretierter Code.

Schutz

Um aus der Anwendungs-Sandbox in einem ordnungsgemäß konfigurierten Gerät auszubrechen, muss man im Allgemeinen die Sicherheit des Linux-Kernels gefährden. Ähnlich wie andere Sicherheitsfunktionen sind jedoch individuelle Schutzmaßnahmen, die die Anwendungs-Sandbox durchsetzen, nicht unverwundbar, daher ist eine Tiefenverteidigung wichtig, um zu verhindern, dass einzelne Schwachstellen zu einer Kompromittierung des Betriebssystems oder anderer Apps führen.

Android verlässt sich auf eine Reihe von Schutzmaßnahmen, um die Anwendungs-Sandbox durchzusetzen. Diese Durchsetzungen 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 Schutzmaßnahmen:

  • In Android 5.0 stellte SELinux eine obligatorische Trennung der Zugriffskontrolle (MAC) zwischen dem System und den Apps bereit. Alle Apps von Drittanbietern liefen jedoch im selben SELinux-Kontext, sodass die Inter-App-Isolierung hauptsächlich durch UID DAC erzwungen wurde.
  • In Android 6.0 wurde die SELinux-Sandbox erweitert, um Apps über die Grenze pro physischem Benutzer 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 wurden alle Apps so eingestellt, dass sie mit einem seccomp-bpf Filter ausgeführt werden, der die Syscalls begrenzte, die Apps verwenden durften, wodurch die App/Kernel-Grenze gestärkt wurde.
  • In Android 9 müssen alle nicht privilegierten Apps mit targetSdkVersion >= 28 in individuellen SELinux-Sandboxen ausgeführt werden, wobei MAC pro App bereitgestellt wird. Dieser Schutz verbessert die App-Trennung, verhindert das Überschreiben sicherer Standardwerte und (am wichtigsten) verhindert, dass Apps ihre Datenwelt zugänglich machen.
  • In Android 10 haben Apps eine eingeschränkte Rohansicht des Dateisystems, ohne direkten Zugriff auf Pfade wie /sdcard/DCIM. Apps behalten jedoch vollen 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 Sicherheitspraxis. Der Zugriff wird allen gewährt und es ist nicht möglich, den Zugriff nur auf den/die beabsichtigten Empfänger zu beschränken. Diese Praxis hat zu Informationslecks und verwirrenden Stellvertreter-Schwachstellen geführt und ist ein bevorzugtes Ziel für Malware, die auf Apps mit sensiblen Daten (z. B. E-Mail-Clients) abzielt. 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, verwenden 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 von weltweit zugänglichen UNIX-Berechtigungen (Einzelheiten finden Sie unter Grundlagen von Inhaltsanbietern ).
  • Wenn Ihre App Dateien enthält, die wirklich für die ganze 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 Einzelheiten zum Hinzufügen eines Medienelements finden Sie unter Zugreifen auf Mediendateien aus dem gemeinsamen Speicher .)

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 Verhalten von Android 10 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) abzielen.
  • Der Standardwert ist false für Apps, die auf Android 10 abzielen. Um die gefilterte Speicheransicht in Apps, die auf Android 10 abzielen, vorübergehend zu deaktivieren, setzen Sie den Wert des Manifest-Flags auf true .
  • Mit eingeschränkten Berechtigungen setzt das Installationsprogramm Apps auf die Whitelist, die für Nicht-Sandbox-Speicher zugelassen sind. Apps, die nicht auf der weißen Liste stehen, werden in einer Sandbox gespeichert.