Questo documento descrive come gli sviluppatori di app possono utilizzare le funzionalità di sicurezza fornite da Android per definire le proprie autorizzazioni. Definendo autorizzazioni personalizzate, un'app può condividere le proprie risorse e funzionalità con altre app. Per saperne di più sulle autorizzazioni, consulta la panoramica delle autorizzazioni.
Sfondo
Android è un sistema operativo con separazione dei privilegi, in cui ogni app viene eseguita con un'identità di sistema distinta (ID utente e ID gruppo Linux). Anche le parti del sistema sono separate in identità distinte. In questo modo, Linux isola le app l'una dall'altra e dal sistema.
Le app possono esporre le proprie funzionalità ad altre app definendo le autorizzazioni che queste ultime possono richiedere. Possono anche definire autorizzazioni che vengono rese automaticamente disponibili per tutte le altre app firmate con lo stesso certificato.
Firma dell'app
Tutti gli APK devono essere firmati con un certificato la cui chiave privata è in possesso dello sviluppatore. Il certificato non deve essere firmato da un'autorità di certificazione. È consentito e tipico per le app per Android utilizzare certificati autofirmati. Lo scopo dei certificati in Android è distinguere gli autori delle app. In questo modo, il sistema può concedere o negare alle app l'accesso alle autorizzazioni a livello di firma e concedere o negare la richiesta di un'app di avere la stessa identità Linux di un'altra app.
Concedi le autorizzazioni di firma dopo la fase di produzione del dispositivo
A partire da Android 12 (livello API 31), l'attributo knownCerts per le autorizzazioni a livello di firma consente di fare riferimento ai digest dei certificati di firma noti al momento della dichiarazione.
Puoi dichiarare l'attributo knownCerts e utilizzare il flag knownSigner nell'attributo protectionLevel della tua app per una determinata autorizzazione a livello di firma. In seguito, il sistema concede l'autorizzazione a un'app richiedente se un firmatario nella derivazione della firma dell'app richiedente, incluso il firmatario corrente, corrisponde a uno dei digest dichiarati con l'autorizzazione nell'attributo knownCerts.
Il flag knownSigner consente a dispositivi e app di concedere autorizzazioni di firma ad altre app senza dover firmare le app al momento della produzione e della spedizione del dispositivo.
ID utente e accesso ai file
Al momento dell'installazione, Android assegna a ogni pacchetto un ID utente Linux distinto. L'identità rimane costante per tutta la durata del pacchetto su quel dispositivo. Su un altro dispositivo, lo stesso pacchetto potrebbe avere un UID diverso. 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 qualsiasi non può normalmente essere eseguito nello stesso processo, in quanto deve essere eseguito come utenti Linux diversi.
A tutti i dati memorizzati da un'app viene assegnato l'ID utente dell'app e normalmente non sono accessibili ad altri pacchetti.
Per saperne di più sul modello di sicurezza di Android, consulta la Panoramica della sicurezza di Android.
Definisci e applica le autorizzazioni
Per applicare le tue autorizzazioni, devi prima dichiararle nel tuo AndroidManifest.xml utilizzando uno o più elementi
<permission>.
Convenzione di denominazione
Il sistema non consente a più pacchetti di dichiarare un'autorizzazione con lo stesso nome, a meno che tutti i pacchetti non 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 questi pacchetti non siano firmati con lo stesso certificato del primo pacchetto.
Ti consigliamo di anteporre alle autorizzazioni il nome del pacchetto di un'app, utilizzando la denominazione in stile dominio inverso, seguita da .permission. e poi da una descrizione della funzionalità rappresentata dall'autorizzazione, in SNAKE_CASE maiuscolo. Ad esempio,
com.example.myapp.permission.ENGAGE_HYPERSPACE.
Seguendo questo suggerimento, eviti conflitti di denominazione e contribuisci a identificare chiaramente il proprietario e lo scopo di un'autorizzazione personalizzata.
Esempio
Ad esempio, un'app che deve controllare quali altre app possono avviare una 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 informare gli utenti delle app che richiedono l'autorizzazione o quali app possono avere l'autorizzazione, come descritto nella documentazione collegata.
L'attributo android:permissionGroup è facoltativo e viene utilizzato solo per aiutare il sistema a mostrare le autorizzazioni all'utente. Nella maggior parte dei casi, imposti questo valore su un gruppo di sistema standard (elencato in android.Manifest.permission_group), anche se puoi definire un gruppo autonomamente, come descritto nella sezione seguente.
Ti consigliamo di utilizzare un gruppo esistente, perché in questo modo l'interfaccia utente delle autorizzazioni mostrata all'utente è più semplice.
Devi fornire sia un'etichetta sia una descrizione per l'autorizzazione. Si tratta di risorse stringa che l'utente può vedere quando visualizza un elenco di autorizzazioni (android:label) o i dettagli di una singola autorizzazione (android:description). L'etichetta è breve: alcune parole che descrivono la funzionalità chiave protetta dall'autorizzazione. La descrizione è costituita da un paio di frasi che descrivono ciò che l'autorizzazione consente di fare a un titolare. La nostra convenzione è una descrizione di due frasi in cui la prima frase descrive l'autorizzazione e la seconda avvisa l'utente del tipo di problemi che possono verificarsi se a un'app viene concessa l'autorizzazione.
Ecco un esempio di etichetta e descrizione per l'autorizzazione CALL_PHONE:
<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 l'attributo android:permissionGroup per aiutare il sistema a descrivere le autorizzazioni all'utente. Nella maggior parte dei casi, questo valore viene impostato su un gruppo di sistema standard (elencato in android.Manifest.permission_group), ma puoi anche definire un gruppo personalizzato con <permission-group>.
L'elemento <permission-group> definisce un'etichetta per un insieme di autorizzazioni, sia quelle dichiarate nel manifest con elementi <permission> sia quelle dichiarate altrove. Questo influisce solo sul modo in cui le autorizzazioni vengono raggruppate quando vengono presentate all'utente. L'elemento <permission-group> non specifica le autorizzazioni che appartengono al gruppo, ma assegna un nome al gruppo.
Puoi inserire un'autorizzazione nel gruppo assegnando il nome del gruppo all'attributo
permissionGroup
dell'elemento
<permission>.
L'elemento <permission-tree> dichiara uno spazio dei nomi per un gruppo di autorizzazioni definite nel codice.
Suggerimenti sulle autorizzazioni personalizzate
Puoi definire autorizzazioni personalizzate per le tue app e richiedere autorizzazioni personalizzate
da altre app definendo gli elementi <uses-permission>.
Tuttavia, valuta attentamente se è necessario farlo.
- Se stai progettando una suite di app che espongono funzionalità l'una all'altra, prova a progettare le app in modo che ogni autorizzazione venga definita una sola volta. Devi farlo se le app non sono tutte firmate con lo stesso certificato. Anche se le app sono tutte firmate con lo stesso certificato, è buona norma definire ogni autorizzazione una sola volta.
- Se la funzionalità è disponibile solo per le app firmate con la stessa firma dell'app che la fornisce, potresti evitare di definire autorizzazioni personalizzate utilizzando i controlli della firma. Quando una delle tue app invia una richiesta a un'altra delle tue app, la seconda app può verificare che entrambe le app siano firmate con lo stesso certificato prima di soddisfare la richiesta.
Se è necessaria un'autorizzazione personalizzata, valuta se l'accesso deve essere consentito solo alle applicazioni firmate dallo stesso sviluppatore dell'applicazione che esegue il controllo delle autorizzazioni, ad esempio quando si implementano comunicazioni tra processi sicure tra due applicazioni dello stesso sviluppatore. In questo caso, ti consigliamo di utilizzare le autorizzazioni di firma. Le autorizzazioni di firma sono trasparenti per l'utente ed evitano le autorizzazioni confermate dall'utente, che possono confonderlo.
Continua a leggere informazioni su:
<uses-permission>- Riferimento API per il tag manifest che dichiara le autorizzazioni di sistema richieste dalla tua app.
Potrebbero interessarti anche:
- Panoramica sulla sicurezza di Android
- Una discussione dettagliata sul modello di sicurezza della piattaforma Android.