Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Anwendungs-Sandbox

Die Android-Plattform nutzt den benutzerbasierten Linux-Schutz, um App-Ressourcen zu identifizieren und zu isolieren. Dies isoliert Apps voneinander und schützt Apps und das System vor schädlichen Apps. Zu diesem Zweck 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 Anwendungssandbox 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, z. B. die Daten von Anwendung B zu lesen oder das Telefon ohne Erlaubnis zu wählen, wird dies verhindert, da es nicht über die entsprechenden Standardbenutzerrechte verfügt. Die Sandbox ist einfach, überprüfbar und basiert auf der jahrzehntelangen Trennung von Prozessen und Dateiberechtigungen durch UNIX-Benutzer.

Da sich die Anwendungssandbox im Kernel befindet, erstreckt sich dieses Sicherheitsmodell sowohl auf systemeigenen 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, eine Reihe von APIs oder eine bestimmte Sprache beschränkt. Unter Android gibt es keine Einschränkungen für das Schreiben einer Anwendung, die zur Durchsetzung der Sicherheit erforderlich sind. In dieser Hinsicht ist nativer Code genauso sandboxed wie interpretierter Code.

Schutz

Im Allgemeinen muss die Sicherheit des Linux-Kernels gefährdet werden, um in einem ordnungsgemäß konfigurierten Gerät aus der Anwendungssandbox auszubrechen. Ähnlich wie bei anderen Sicherheitsfunktionen sind einzelne Schutzmaßnahmen, die die Anwendungssandbox erzwingen, nicht unverwundbar. Daher ist eine gründliche Verteidigung wichtig, um zu verhindern, dass einzelne Sicherheitslücken zu einer Gefährdung des Betriebssystems oder anderer Apps führen.

Android stützt sich auf eine Reihe von Schutzmaßnahmen, um die Anwendungssandbox zu erzwingen. 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 den folgenden Schutz:

  • In Android 5.0 stellte SELinux eine obligatorische MAC-Trennung (Access Control) zwischen dem System und den Apps bereit. Alle Apps von Drittanbietern wurden jedoch im selben SELinux-Kontext ausgeführt, sodass die Isolierung zwischen Apps hauptsächlich vom UID-DAC erzwungen wurde.
  • In Android 6.0 wurde die SELinux-Sandbox erweitert, um Apps über die Grenzen pro physischem Benutzer hinweg zu isolieren. Darüber hinaus hat Android sicherere Standardeinstellungen für Anwendungsdaten festgelegt: Für Apps mit targetSdkVersion >= 24 wurden die Standard-DAC-Berechtigungen für das Home- targetSdkVersion >= 24 einer App von 751 auf 700 geändert. Dies stellte sicherere Standardeinstellungen für private App-Daten bereit (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, die Apps verwenden durften, einschränkte und so die Grenze zwischen App und Kernel verstä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 (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 uneingeschränkten Zugriff auf ihre paketspezifischen Pfade, wie dies von allen anwendbaren Methoden wie Context.getExternalFilesDir () zurückgegeben wird .

Richtlinien für die Freigabe von Dateien

Das Festlegen von App-Daten als weltweit zugänglich ist eine schlechte Sicherheitspraxis. Der Zugriff wird jedem gewährt und es ist nicht möglich, den Zugriff nur auf die beabsichtigten Empfänger zu beschränken. Diese Vorgehensweise hat zu Informationslecks und verwirrten Sicherheitslücken geführt und ist ein beliebtes Ziel für Malware, die auf Apps mit vertraulichen Daten abzielt (z. B. E-Mail-Clients). In Android 9 und höher ist das targetSdkVersion>=28 Dateien auf diese Weise für Apps mit targetSdkVersion>=28 ausdrücklich nicht targetSdkVersion>=28 .

Verwenden Sie beim Freigeben von Dateien die folgenden Richtlinien, anstatt App-Daten weltweit zugänglich zu machen:

  • Wenn Ihre App Dateien für eine andere App freigeben 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 in den Grundlagen der Inhaltsanbieter ).
  • Wenn Ihre App Dateien enthält, auf die die Welt wirklich zugreifen sollte (z. B. Fotos), müssen diese medienspezifisch sein (nur Fotos, Videos und Audiodateien) und mithilfe der MediaStore- Klasse gespeichert werden. (Weitere Informationen finden Sie in der Vorschau des DAC .)

Die Speicherlaufzeitberechtigung 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 .

Verwenden Sie das Manifestattribut requestLegacyExternalStorage , um das Verhalten von Android 10 zu requestLegacyExternalStorage , und befolgen Sie die Best Practices für App-Berechtigungen .

  • Der Standardwert für das Manifest-Flag true für Apps für Android 9 (und niedriger).
  • Der Standardwert ist für Apps für Android 10 falsch. Um die gefilterte Speicheransicht in Apps für Android 10 vorübergehend zu deaktivieren, setzen Sie den Wert des Manifest-Flags auf true .
  • Mit eingeschränkten Berechtigungen listet das Installationsprogramm Apps auf, die für Speicher ohne Sandbox zulässig sind. Nicht auf der Whitelist stehende Apps sind in einer Sandbox gespeichert.