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 diese 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. Apps können standardmäßig nicht miteinander interagieren und haben nur eingeschränkten Zugriff auf das Betriebssystem. Wenn App A versucht, etwas Schädliches zu tun, z. B. die Daten von Anwendung B zu lesen oder das Telefon ohne Erlaubnis anzurufen, wird sie daran gehindert, weil sie nicht über die entsprechenden Standardbenutzerberechtigungen verfügt. Die Sandbox ist einfach, überprüfbar und basiert auf der jahrzehntealten UNIX-artigen Benutzertrennung von Prozessen und Dateiberechtigungen.

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 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 Sprache beschränkt. Auf Android gibt es keine Einschränkungen beim Schreiben einer Anwendung, die erforderlich sind, um die Sicherheit zu erzwingen. In dieser Hinsicht ist nativer Code genauso sandkastenförmig wie interpretierter Code.

Schutzmaßnahmen

Um aus der Application Sandbox in einem richtig konfigurierten Gerät auszubrechen, muss man im Allgemeinen die Sicherheit des Linux-Kernels kompromittieren. Ähnlich wie bei anderen Sicherheitsfunktionen sind jedoch einzelne Schutzmaßnahmen, die die Anwendungs-Sandbox erzwingen, nicht unverwundbar, daher ist eine Tiefenverteidigung wichtig, um zu verhindern, dass einzelne Sicherheitslücken zu einer Kompromittierung des Betriebssystems oder anderer Anwendungen führen.

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

  • In Android 5.0 bot SELinux eine obligatorische Zugriffssteuerung (MAC)-Trennung zwischen dem System und den Apps. Alle Apps von Drittanbietern liefen jedoch im selben SELinux-Kontext, sodass die Isolation zwischen Apps hauptsächlich von UID DAC erzwungen wurde.
  • In Android 6.0 wurde die SELinux-Sandbox erweitert, um Apps über die Grenze pro physischem Benutzer hinweg zu isolieren. Darüber hinaus setzen Android auch sichere Standardeinstellung für Anwendungsdaten: Für Anwendungen mit targetSdkVersion >= 24 , Standard - DAC Berechtigungen für eine Home - Verzeichnis der App von 751 bis 700. Dieser sicheren Standard für private App - Daten zur Verfügung gestellt geändert (obwohl Apps diese Standardwerte außer Kraft setzen kann) .
  • In Android 8.0 wurden alle Anwendungen gesetzt mit einem laufen seccomp-bpf - Filter, der den syscalls begrenzt , dass Apps Gebrauch gestattet wurde, so dass die app / kernel Grenze zu stärken.
  • In Android 9 alle nicht-privilegierten Anwendungen mit targetSdkVersion >= 28 muss in einzelnen SELinux Sandkästen laufen, bietet MAC auf einer Pro-App - Basis. Dieser Schutz verbessert die App-Trennung, verhindert das Überschreiben sicherer Standardeinstellungen und (vor allem) 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. Allerdings Apps behalten die volle rohen Zugriff auf ihre paketspezifische Wege, wie durch die anwendbaren Methoden zurückgegeben, wie Context.getExternalFilesDir () .

Richtlinien zum Teilen 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 den/die vorgesehenen Empfänger zu beschränken. Diese Praxis hat zu Informationslecks und verwirrenden Sicherheitslücken bei Stellvertretern geführt und ist ein beliebtes Ziel für Malware, die auf Apps mit sensiblen Daten (wie E-Mail-Clients) abzielt. In Android 9 und höher, gemeinsame Nutzung von Dateien auf diese Weise explizit für Anwendungen mit nicht erlaubt ist targetSdkVersion>=28 .

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

  • Wenn Ihre App Bedürfnisse gemeinsame Nutzung von Dateien mit einer anderen App, verwenden Sie einen Content - Provider . Content - Anbieter teilen Daten mit der richtigen Granularität und ohne die vielen Nachteile der Welt zugänglich UNIX - Berechtigungen (für Details siehe Content - Provider - Grundlagen ).
  • Wenn Ihre App - Dateien hat , die wirklich in der Welt (wie Fotos) zugänglich sein soll, müssen sie medienspezifische (Fotos, Videos und Audio-Dateien) und gespeichert unter Verwendung der sein Mediastor Klasse. (Weitere Informationen darüber , wie ein Medien - Objekt hinzufügen, finden Sie Mediendateien von gemeinsam genutzten Speicher .)

Die Speicherlaufzeit Erlaubnis steuert den Zugriff auf stark typisierte Sammlungen durch Mediastor. Schwach typisierte Dateien wie PDFs und die für den Zugriff auf MediaStore.Downloads Klasse muss apps Absichten wie die Verwendung ACTION_OPEN_DOCUMENT Absicht.

Android 10 Verhalten, verwenden Sie das ermöglichen requestLegacyExternalStorage manifestieren Attribut, und folgen Sie App - Berechtigungen Best Practices .

  • Der Manifest - Flag Standardwert ist true für Anwendungen Targeting Android 9 (und niedriger).
  • Der Standardwert ist false für Apps Android 10. Um Targeting vorübergehend deaktivieren des gefilterten Speicheransicht in App - Targeting Android 10, stellen Sie den offensichtlichen Flagge Wert true .
  • Mit eingeschränkten Berechtigungen setzt das Installationsprogramm Apps auf die Whitelist, die für die Speicherung ohne Sandbox zugelassen sind. Apps, die nicht auf der Whitelist stehen, werden in einer Sandbox verwendet.