Questo documento descrive in che modo gli sviluppatori di app possono utilizzare funzionalità di sicurezza fornite da Android per definire le proprie autorizzazioni. Di definendo autorizzazioni personalizzate, un'app può condividere le proprie risorse con altre app. Per ulteriori informazioni sulle autorizzazioni, consulta la panoramica delle autorizzazioni.
Premessa
Android è un sistema operativo separato da privilegi, in cui L'app viene eseguita con un'identità di sistema distinta (ID utente e gruppo Linux ID). Anche alcune parti del sistema sono separate in identità distinte. In questo modo, Linux isola le app tra loro e dal sistema.
Le app possono esporre la propria funzionalità ad altre app definendo autorizzazioni richieste da altre app. Può anche definire autorizzazioni vengono automaticamente resi disponibili a qualsiasi altra app collegata lo stesso certificato.
Firma dell'app
Tutti gli APK devono essere firmati con un certificato la cui chiave privata è conservata dallo sviluppatore. Il certificato non devono essere firmati da un'autorità di certificazione. È consentito tipico, per le app Android di usare certificati autofirmati. Lo scopo di in Android è distinguere gli autori delle app. Ciò consente il sistema conceda o nega alle app l'accesso a livello di firma autorizzazioni e concedere o negare la richiesta di concessione di un'app la stessa identità Linux di un'altra app.
Concedi autorizzazioni di firma al termine della produzione del dispositivo
A partire da Android 12 (livello API 31), la
Attributo knownCerts
per
le autorizzazioni a livello di firma consentono di fare riferimento alle sintesi delle
certificati al momento della dichiarazione
nel tempo.
Puoi dichiarare l'attributo knownCerts
e utilizzare il flag knownSigner
nel protectionLevel
della tua app
attributo
per una particolare autorizzazione a livello di firma. Quindi, il sistema
concede questa autorizzazione all'app richiedente a qualsiasi firmatario nell'app richiedente
la derivazione, compreso l'attuale firmatario, corrisponde a una delle digest
dichiarato con l'autorizzazione nell'attributo knownCerts
.
Il flag knownSigner
consente a dispositivi e app di concedere autorizzazioni di firma a
altre app senza doverle firmare al momento della produzione del dispositivo
e della spedizione.
ID utente e accesso ai file
Al momento dell'installazione, Android assegna a ogni pacchetto un ID utente Linux distinto. La l'identità rimane costante per tutta la durata del pacchetto su quel dispositivo. Su un altro dispositivo, lo stesso pacchetto potrebbe avere un indirizzo UID: l'importante è che ogni pacchetto abbia un UID distinto su un determinato dispositivo.
Poiché l'applicazione della sicurezza avviene a livello di processo, il codice di due pacchetti non può devono essere eseguiti nello stesso processo, poiché devono essere eseguiti da utenti Linux diversi.
Tutti i dati archiviati da un'app vengono assegnati all'utente dell'app e non è normalmente accessibile agli altri pacchetti.
Per ulteriori informazioni sul modello di sicurezza di Android, vedi Sicurezza Android Panoramica.
Definisci e applica le autorizzazioni
Per applicare le tue autorizzazioni, devi prima dichiararle nel tuo
AndroidManifest.xml
utilizzando uno o più
<permission>
.
Convenzione di denominazione
Il sistema non consente a più pacchetti di un'autorizzazione con lo stesso nome, a meno che tutti i pacchetti siano firmati con lo stesso certificato. Se un pacchetto dichiara un'autorizzazione, il sistema non consente all'utente di installare altri pacchetti con lo stesso nome di autorizzazione, a meno che quei pacchetti sono firmati con lo stesso certificato del primo pacchetto.
È consigliabile aggiungere il nome del pacchetto dell'app prima alle autorizzazioni, utilizzando
denominazione in stile dominio inverso, seguita da .permission.
e una descrizione della funzionalità rappresentata dall'autorizzazione,
SNAKE_CASE in alto. Ad esempio:
com.example.myapp.permission.ENGAGE_HYPERSPACE
.
Seguendo questo consiglio si evitano conflitti di denominazione Identificare il proprietario e l'intenzione di un'autorizzazione personalizzata.
Esempio
Ad esempio, un'app che deve controllare quali altre app possono avviare delle sue attività può dichiarare un'autorizzazione per questa operazione come segue:
<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>
L'attributo
protectionLevel
è obbligatorio e indica al sistema come
comunicare agli utenti le app che richiedono l'autorizzazione
detenere l'autorizzazione, come descritto nella documentazione collegata.
La android:permissionGroup
è facoltativo e viene utilizzato solo per aiutare il sistema a visualizzare le autorizzazioni
all'utente. Nella maggior parte dei casi, lo imposti su un sistema standard
gruppo (elencato in android.Manifest.permission_group
),
anche se puoi definire un gruppo autonomamente, come descritto nella sezione seguente.
Consigliamo di utilizzare un gruppo esistente per semplificare il
di autorizzazione mostrata all'utente.
Devi fornire sia un'etichetta sia una descrizione per il
autorizzazione. Si tratta di risorse di tipo stringa che l'utente può visualizzare
sta visualizzando un elenco di autorizzazioni
(android:label
)
o dettagli su una singola autorizzazione
(android:description
).
L'etichetta è breve: poche parole che descrivono l'elemento chiave
la funzionalità protetta
dall'autorizzazione. La descrizione è
due frasi che descrivono cosa consente l'autorizzazione all'utente. Le nostre
è una descrizione di due frasi in cui la prima descrive
l'autorizzazione e la seconda frase avverte l'utente del tipo di
che possono andare storte se viene concessa l'autorizzazione a un'app.
Di seguito è riportato un esempio di etichetta e descrizione per
CALL_PHONE
autorizzazione:
<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>
Crea un gruppo di autorizzazioni
Come mostrato nella sezione precedente, puoi utilizzare
Attributo android:permissionGroup
per aiutare il sistema a descrivere
autorizzazioni all'utente. Nella maggior parte dei casi, lo imposti sul modello
gruppo di sistema (elencato in
android.Manifest.permission_group
),
ma puoi anche definire il tuo gruppo
<permission-group>
.
L'elemento <permission-group>
definisce un'etichetta per un insieme
di autorizzazioni, entrambe dichiarate nel manifest con
<permission>
e quelli dichiarati altrove. Ciò influisce solo sul modo in cui le autorizzazioni
raggruppate quando vengono presentate all'utente. La
<permission-group>
non specifica le autorizzazioni appartenenti al gruppo, ma
assegna un nome al gruppo.
Puoi inserire un'autorizzazione nel gruppo assegnando il nome al gruppo
<permission>
dell'elemento
permissionGroup
.
La
<permission-tree>
dichiara uno spazio dei nomi per un gruppo di autorizzazioni definite
le API nel tuo codice.
Suggerimenti sulle autorizzazioni personalizzate
Puoi definire autorizzazioni personalizzate per le tue app e richiedere autorizzazioni personalizzate
da altre app definendo elementi <uses-permission>
.
Tuttavia, valuta attentamente se è necessario.
- Se stai progettando una suite di app che espongono funzionalità a uno un'altra, prova a progettare le app in modo che ogni autorizzazione sia definita solo una volta sola. Devi eseguire questa operazione se le app non sono tutte firmate con lo stesso certificato. Anche se le app sono tutte firmate con lo stesso certificato, è consigliabile definire ogni autorizzazione una sola volta.
- Se la funzionalità è disponibile soltanto per le app firmate con lo stesso firma dell'app che ha fornito il servizio, potresti evitare di definire autorizzazioni mediante controlli della firma. Quando una delle tue app effettua una richiesta di un'altra app, la seconda può verificare che entrambe le app siano firmate con lo stesso certificato prima di soddisfare la richiesta.
Se è necessaria un'autorizzazione personalizzata, valuta se sono disponibili solo le applicazioni firmate dallo stesso sviluppatore dell'applicazione che esegue il controllo delle autorizzazioni accedervi, ad esempio quando implementi comunicazioni sicure tra i processi tra due applicazioni dello stesso sviluppatore. In questo caso, ti consigliamo di utilizzare autorizzazioni con firma. Le autorizzazioni alla firma sono trasparenti per l'utente ed evitano che vengano confermate dall'utente autorizzazioni, il che può confondere gli utenti.
Continua a leggere su:
<uses-permission>
- Riferimento API per il tag manifest che dichiara le autorizzazioni di sistema richieste per l'app.
Potrebbe interessarti anche:
- Panoramica sulla sicurezza di Android
- Una discussione dettagliata sul modello di sicurezza della piattaforma Android.