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 eine eindeutige Nutzer-ID (UID) für jede Android-App und führt sie in ihrer eigenen .

Android verwendet die UID, um eine Application 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 Schädliches zu tun, z. B. das Lesen von oder das Telefon ohne Erlaubnis anrufen möchten, wird sie daran gehindert, da sie nicht über die entsprechenden Standardberechtigungen verfügt. 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 Entwickelnde sind auf ein bestimmtes Entwicklungs-Framework, eine Reihe von APIs oder Sprache. Unter Android gibt es keine Einschränkungen für die Erstellung einer App, die zur 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. Ähnliche auf andere Sicherheitsfunktionen, individuelle Schutzmaßnahmen Sandbox-Technologie nicht unverwundbar sind. Daher ist es wichtig, gestaffelte Sicherheitsebenen zu verhindern, einzelne Schwachstellen, die zur Kompromittierung des Betriebssystems oder anderer Apps führen.

Android setzt eine Reihe von Schutzmaßnahmen ein, um die App-Sandbox durchzusetzen. Diese Verstöße wurden nach und nach eingeführt und die ursprüngliche UID-basierte diskretionäre Zugriffssteuerung erheblich verbessert. (DAC) Sandbox ausführen. Zu früheren Android-Releases gehörten Folgendes: Schutzmaßnahmen:

  • In Android 5.0 sorgte SELinux für eine MAC-Trennung (Mandatory Access Control) zwischen System und Apps. Alle Drittanbieter-Apps laufen jedoch im selben SELinux-Kontext, sodass die Isolierung zwischen Apps primär 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 App-Daten: Standard für Apps mit targetSdkVersion >= 24 Die DAC-Berechtigungen für das Startverzeichnis einer App wurden von 751 in 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, wobei MAC pro App bereitgestellt wird. zu verstehen. Dieser Schutz verbessert die App-Trennung und verhindert das Überschreiben von Safe und verhindert vor allem, dass Apps ihre Daten zur Welt machen. zugänglich zu machen.
  • In Android 10-Apps ist die Ansicht der ohne 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. Zugriff und es ist nicht möglich, den Zugriff nur auf die Empfänger. 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 für eine andere App freigeben muss, verwenden Sie ein Contentanbieter. 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.
  • Ob Ihre App Dateien enthält, die wirklich für alle Nutzer zugänglich sein sollten (z. B. Fotos) müssen medienspezifisch sein (z. B. Fotos, Videos und Audiodateien). und mit dem MediaStore-Klasse. Weitere Informationen zum Hinzufügen von Medien siehe Zugriff auf Mediendateien aus freigegebenem Speicher.

Die Laufzeitberechtigung Speicher steuert den Zugriff über MediaStore auf typisierte Sammlungen zu verweisen. 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. Um den Filter vorübergehend zu deaktivieren, in Apps, die auf Android 10 ausgerichtet sind, 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.