Benutzerdefinierte App-Berechtigung festlegen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Dokument wird beschrieben, wie App-Entwickler die Sicherheitsfunktionen von Android, um eigene Berechtigungen zu definieren. Durch das Definieren benutzerdefinierter Berechtigungen kann eine App ihre Ressourcen und Funktionen für andere Apps freigeben. Weitere Informationen zu Berechtigungen finden Sie in der Berechtigungsübersicht.

Hintergrund

Android ist ein privilegiertes Betriebssystem, App wird mit einer eindeutigen Systemidentität ausgeführt (Linux-Nutzer-ID und -Gruppe). ID). Teile des Systems werden auch in verschiedene Identitäten unterteilt. So werden Apps voneinander und vom System isoliert.

Durch das Definieren von Berechtigungen können Apps ihre Funktionen für andere Apps freigeben die andere Apps anfordern können. Sie können auch Berechtigungen definieren, die automatisch für alle anderen Apps verfügbar gemacht werden, die mit demselben Zertifikat signiert sind.

App-Signatur

Alle APKs müssen mit einem Zertifikat signiert sein, dessen privater Schlüssel vom Entwickler gehalten wird. Das Zertifikat muss nicht von einer Zertifizierungsstelle signiert sein. Es ist zulässig und üblich, dass Android-Apps selbst signierte Zertifikate verwenden. Der Zweck der um App-Autoren zu unterscheiden. So kann das System Apps Zugriff auf Berechtigungen auf Signaturebene gewähren oder verweigern und die Anfrage einer App, dieselbe Linux-Identität wie eine andere App zu erhalten, gewähren oder ablehnen.

Signaturberechtigungen nach der Herstellung des Geräts erteilen

Ab Android 12 (API-Ebene 31) können Sie mit dem Attribut knownCerts für Berechtigungen auf Signaturebene zum Zeitpunkt der Deklaration auf die Hash-Werte bekannter Signaturzertifikate verweisen.

Sie können das Attribut knownCerts deklarieren und das Flag knownSigner verwenden in der protectionLevel Ihrer App Attribut für eine bestimmte Berechtigung auf Signaturebene. Anschließend gewährt das System diese Berechtigung einer anfragenden App, wenn einer der Unterzeichner in der Signaturabfolge der anfragenden App, einschließlich des aktuellen Unterzeichners, mit einem der Digests übereinstimmt, die im Attribut knownCerts mit der Berechtigung deklariert sind.

Mit dem Flag knownSigner können Geräte und Apps anderen Apps Signaturberechtigungen gewähren, ohne dass die Apps bei der Geräteherstellung und -lieferung signiert werden müssen.

Nutzer-IDs und Dateizugriff

Bei der Installation weist Android jedem Paket eine eindeutige Linux-Nutzer-ID zu. Die Identität bleibt während der Lebensdauer des Pakets auf diesem Gerät konstant. Auf einem anderen Gerät hat dasselbe Paket möglicherweise ein anderes UID: Wichtig ist, dass jedes Paket eine eigene UID auf einer bestimmten .

Da die Sicherheitsdurchsetzung auf Prozessebene erfolgt, kann der Code von zwei Paketen normalerweise nicht im selben Prozess ausgeführt werden, da sie als unterschiedliche Linux-Nutzer ausgeführt werden müssen.

Allen von einer App gespeicherten Daten wird die User-ID dieser App zugewiesen. Normalerweise können andere Pakete nicht darauf zugreifen.

Weitere Informationen zum Sicherheitsmodell von Android finden Sie unter Sicherheit bei Android Übersicht.

Berechtigungen definieren und durchsetzen

Um Ihre eigenen Berechtigungen zu erzwingen, müssen Sie diese zuerst in Ihren AndroidManifest.xml mit einem oder mehreren <permission>-Elemente.

Namenskonvention

Das System erlaubt nicht, dass mehrere Pakete eine Berechtigung mit demselben Namen deklarieren, es sei denn, alle Pakete sind mit demselben Zertifikat signiert. Wenn ein Paket eine Berechtigung deklariert, kann das System auch keine Nutzern erlauben, andere Pakete mit demselben Berechtigungsnamen zu installieren, es sei denn, diese Pakete mit demselben Zertifikat wie das erste Paket signiert sind.

Wir empfehlen, den Berechtigungen den Paketnamen einer App voranzustellen. Verwenden Sie dazu Reverse-Domain-ähnliche Benennung, gefolgt von .permission. und eine Beschreibung der Capability, die die Berechtigung repräsentiert, SNAKE_CASE oben. Beispiel: com.example.myapp.permission.ENGAGE_HYPERSPACE.

Wenn Sie dieser Empfehlung folgen, lassen sich Namenskollisionen vermeiden und der Inhaber und die Absicht einer benutzerdefinierten Berechtigung lassen sich klar identifizieren.

Beispiel

Beispiel: Eine App, die steuern muss, welche anderen Apps eine solche App starten können, seiner Aktivitäten kann wie folgt eine Berechtigung für diesen Vorgang deklarieren:

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

Das Attribut protectionLevel ist erforderlich und teilt dem System mit, wie Nutzer über Apps informieren, für die eine Berechtigung erforderlich ist, oder darüber, welche Apps die Berechtigung haben, wie in der verlinkten Dokumentation beschrieben.

Die android:permissionGroup ist optional und dient nur dazu, dem System die Anzeige von Berechtigungen zu erleichtern. für den Nutzer. In den meisten Fällen legen Sie hier eine Standardsystemgruppe fest (in android.Manifest.permission_group aufgeführt). Sie können aber auch eine Gruppe selbst definieren, wie im folgenden Abschnitt beschrieben. Wir empfehlen die Verwendung einer vorhandenen Gruppe, da dies die Berechtigungs-UI, die dem Nutzer angezeigt wird.

Sie müssen sowohl ein Label als auch eine Beschreibung für die Berechtigung angeben. Dies sind Stringressourcen, die Nutzer sehen, wenn sie sich eine Liste der Berechtigungen (android:label) oder Details zu einer einzelnen Berechtigung (android:description) ansehen. Das Label ist kurz: Es beschreibt in wenigen Worten die Hauptfunktion, die durch die Berechtigung geschützt wird. Die Beschreibung ist ein beschreiben, was ein Inhaber mit der Berechtigung tun kann. Unsere ist eine Beschreibung aus zwei Sätzen, wobei der erste Satz Mit der Berechtigung wird der Nutzer im zweiten Satz darauf hingewiesen, die schiefgehen können, wenn einer App die Berechtigung gewährt wird.

Hier sehen Sie ein Beispiel für ein Label und eine Beschreibung für die CALL_PHONE Berechtigung:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

Berechtigungsgruppe erstellen

Wie im vorherigen Abschnitt gezeigt, können Sie das Attribut android:permissionGroup verwenden, um dem System zu helfen, Berechtigungen für den Nutzer zu beschreiben. In den meisten Fällen legen Sie dafür eine Standard- Systemgruppe (aufgeführt in android.Manifest.permission_group) Sie können aber auch Ihre eigene Gruppe mit <permission-group>.

Das Element <permission-group> definiert ein Label für eine Reihe von Berechtigungen, sowohl für die im Manifest mit <permission>-Elementen deklarierten als auch für die an anderer Stelle deklarierten. Dies wirkt sich nur darauf aus, wie die Berechtigungen für den Nutzer gruppiert werden. Die <permission-group> nicht die Berechtigungen angibt, die zur Gruppe gehören, aber erhält die Gruppe einen Namen.

Sie können der Gruppe eine Berechtigung zuweisen, indem Sie den Gruppennamen <permission> des Elements permissionGroup .

Die <permission-tree> deklariert einen Namespace für eine Gruppe von Berechtigungen, die in Code.

Benutzerdefinierte Empfehlungen für Berechtigungen

Sie können benutzerdefinierte Berechtigungen für Ihre Apps festlegen und benutzerdefinierte Berechtigungen anfordern aus anderen Apps generieren, indem Sie <uses-permission>-Elemente definieren. Sie sollten jedoch sorgfältig abwägen, ob dies erforderlich ist.

• Wenn Sie eine Suite von Apps entwerfen, Versuchen Sie, die Apps so zu gestalten, dass jede Berechtigung nur definiert ist, einmal. Dieser Schritt ist erforderlich, wenn nicht alle Apps mit demselben Zertifikat. Auch wenn alle Apps mit demselben Zertifikat signiert sind, Es empfiehlt sich, jede Berechtigung nur einmal zu definieren.
• Wenn die Funktion nur für Apps verfügbar ist, die mit demselben als bereitstellende App verwenden möchten, müssen Sie möglicherweise keine benutzerdefinierten mithilfe von Signaturprüfungen. Wenn eine Ihrer Apps eine Anfrage an eine andere Ihrer Apps sendet, kann die zweite App prüfen, ob beide Apps mit demselben Zertifikat signiert sind, bevor sie der Anfrage nachkommt.

Wenn eine benutzerdefinierte Berechtigung erforderlich ist, überlegen Sie, ob nur Anwendungen vom selben Entwickler wie die App, die die Berechtigungsprüfung durchführt, z. B. bei der Implementierung einer sicheren prozessübergreifenden Kommunikation zwischen zwei Apps vom selben Entwickler. In diesem Fall sollten Sie Signaturberechtigungen. Unterschriftenberechtigungen sind für Nutzer transparent und es werden keine vom Nutzer bestätigten Berechtigungen verwendet, die für Nutzer verwirrend sein können.