In diesem Dokument wird beschrieben, wie App-Entwickler die Sicherheitsfunktionen von Android, um eigene Berechtigungen zu definieren. Von indem benutzerdefinierte Berechtigungen festgelegt werden, kann eine App ihre Ressourcen und Funktionen freigeben. mit anderen Apps. 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 ebenfalls in verschiedene Identitäten unterteilt. Auf diese Weise isoliert Linux Apps voneinander und vom System.
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, werden automatisch auch anderen Apps zur Verfügung gestellt, die mit dem über dasselbe Zertifikat.
App-Signatur
Alle APKs müssen mit einem Zertifikat signiert werden. dessen privater Schlüssel vom Entwickler verwaltet wird. Das Zertifikat enthält nicht von einer Zertifizierungsstelle signiert sein. Es ist zulässig und Üblicherweise verwenden Android-Apps selbstsignierte Zertifikate. Der Zweck der um App-Autoren zu unterscheiden. Dadurch können Apps Zugriff auf Signaturebene gewähren oder verweigern. Berechtigungen und gewähren oder lehnen Sie die Anfrage einer App zum Erteilen dieselbe Linux-Identität wie eine andere Anwendung.
Signaturberechtigungen nach der Herstellung des Geräts erteilen
Ab Android 12 (API-Level 31)
Attribut knownCerts
für
Mit Berechtigungen auf Signaturebene können Sie auf die Digests bekannter Signaturen
Bescheinigungen bei der Erklärung
.
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. Dann wird das System
gewährt einer anfragenden App diese Berechtigung, wenn ein Unterzeichner in der
Signatur Lineage, einschließlich des aktuellen Unterzeichners,
stimmt mit einer der Digests überein,
mit der Berechtigung im Attribut knownCerts
deklariert.
Mit dem Flag knownSigner
können Geräte und Apps Berechtigungen für Signaturen erteilen
andere Apps verwenden, ohne sie bei der Geräteherstellung signieren zu müssen
und Versand.
Nutzer-IDs und Dateizugriff
Bei der Installation weist Android jedem Paket eine eigene Linux-Nutzer-ID zu. Die Identität für die Lebensdauer des Pakets auf dieser Seite konstant bleibt. . Auf einem anderen Gerät hat dasselbe Paket möglicherweise ein anderes UID: Wichtig ist, dass jedes Paket eine eigene UID auf einer bestimmten .
Die Sicherheitsdurchsetzung erfolgt kann der Code zweier Pakete normalerweise nicht im selben Prozess ausgeführt werden, da sie als verschiedene Linux-Nutzer ausgeführt werden müssen.
Alle von einer App gespeicherten Daten werden dem Nutzer dieser App zugewiesen ID und ist normalerweise für andere Pakete nicht zugänglich.
Weitere Informationen zum Sicherheitsmodell von Android finden Sie unter Sicherheit bei Android Übersicht.
Berechtigungen definieren und erzwingen
Um Ihre eigenen Berechtigungen zu erzwingen, müssen Sie diese zuerst in Ihren
AndroidManifest.xml
mit einem oder mehreren
<permission>
-Elemente.
Namenskonvention
Das System lässt nicht zu, dass mehrere Pakete deklariert werden. eine Berechtigung mit demselben Namen, es sei denn, alle Pakete sind mit dem über dasselbe Zertifikat. 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 diese Empfehlung befolgen, vermeiden Sie Konflikte bei der Benennung den Inhaber und die Absicht einer benutzerdefinierten Berechtigung ermitteln.
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 ein Standardsystem fest,
Gruppe (aufgeführt in android.Manifest.permission_group
),
obwohl Sie eine Gruppe selbst definieren können, 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. Dies sind String-Ressourcen, die der Nutzer sehen kann,
sehen sie sich eine Liste mit Berechtigungen an
(android:label
)
oder Details zu einer Berechtigung,
(android:description
)
Das Label ist kurz: ein paar Wörter, die das Wichtigste
Funktionen, die durch die Berechtigung geschützt werden. Die Beschreibung ist ein
beschreiben, was
der Inhaber mit der Berechtigung tun lässt. 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
android:permissionGroup
-Attribut zum Beschreiben von
Berechtigungen für den Nutzer zu gewähren. 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 Gruppe.
der im Manifest deklarierten Berechtigungen
<permission>
und an anderer Stelle deklarierte Elemente. Dies wirkt sich nur auf die Berechtigungen aus,
gruppiert werden, wenn sie
dem Nutzer präsentiert 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
durch die Definition von <uses-permission>
-Elementen aus anderen Apps.
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 die Apps nicht alle 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 stellt deiner anderen Apps überprüft, kann die zweite App prüfen, ob beide Apps signiert sind. das gleiche Zertifikat erhalten, bevor Sie der Anfrage nachkommen.
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. Signaturberechtigungen sind für den Nutzer transparent und müssen nicht bestätigt werden was für Nutzer verwirrend sein kann.
Lesen Sie weiter zu:
<uses-permission>
- API-Referenz für das Manifest-Tag, mit dem die erforderlichen Systemberechtigungen für deine App deklariert sind
Das könnte Sie auch interessieren:
- Android-Sicherheit – Übersicht
- Eine ausführliche Diskussion zum Sicherheitsmodell der Android-Plattform.