Definisci un'autorizzazione app personalizzata

Questo documento descrive come gli sviluppatori di app possono utilizzare le funzionalità di sicurezza fornite da Android per definire le proprie autorizzazioni. Mediante la definizione di autorizzazioni personalizzate, un'app può condividere le proprie risorse e funzionalità con altre app. Per ulteriori informazioni sulle autorizzazioni, consulta la panoramica delle autorizzazioni.

Premessa

Android è un sistema operativo con privilegi separati in cui ogni app viene eseguita con una diversa identità di sistema (ID utente Linux e ID gruppo). Parti del sistema sono inoltre separate in identità distinte. Linux isola le app l'una dall'altra e dal sistema.

Le app possono esporre la propria funzionalità ad altre app definendo le autorizzazioni che altre app possono richiedere. Possono inoltre definire autorizzazioni che vengono rese automaticamente disponibili per qualsiasi altra app firmata 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. Generalmente, le app per Android possono 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 a un'app la richiesta di ottenere la stessa identità Linux di un'altra app.

Concedi le autorizzazioni di firma al termine della produzione del dispositivo

A partire da Android 12 (livello API 31), l'attributo knownCerts per le autorizzazioni a livello di firma ti 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. Quindi, il sistema concede l'autorizzazione a un'app richiedente se un firmatario nella derivazione di firma dell'app richiedente, incluso il firmatario attuale, corrisponde a uno dei digest dichiarati con l'autorizzazione nell'attributo knownCerts.

Il flag knownSigner consente ai dispositivi e alle 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 l'intera durata del ciclo di vita del pacchetto sul dispositivo. Su un dispositivo diverso, lo stesso pacchetto potrebbe avere un UID diverso, ma è 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 di solito non può essere eseguito nello stesso processo, in quanto devono essere eseguiti come utenti Linux diversi.

A tutti i dati archiviati da un'app viene assegnato il relativo ID utente e non sono normalmente accessibili ad altri pacchetti.

Per maggiori informazioni sul modello di sicurezza di Android, consulta la Panoramica sulla sicurezza di Android.

Definisci e applica le autorizzazioni

Per applicare le tue autorizzazioni, devi prima dichiararle in 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 i pacchetti non siano firmati con lo stesso certificato del primo pacchetto.

Ti consigliamo di anteporre il nome del pacchetto di un'app alle autorizzazioni, utilizzando la denominazione in stile dominio inverso, seguita da .permission. e da una descrizione della funzionalità rappresentata dall'autorizzazione, con la dicitura SNAKE_CASE superiore. Ad esempio, com.example.myapp.permission.ENGAGE_HYPERSPACE.

Se segui questo suggerimento, eviti conflitti di denominazione e aiuti a identificare chiaramente il proprietario e l'intento 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 nel seguente modo:

<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 di quali app possono mantenere 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, puoi impostarlo su un gruppo di sistema standard (elencato in android.Manifest.permission_group), anche se puoi definire un gruppo personalmente, come descritto nella sezione seguente. Ti consigliamo di utilizzare un gruppo esistente, poiché ciò semplifica l'interfaccia utente delle autorizzazioni mostrata all'utente.

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: poche parole che descrivono l'elemento chiave della funzionalità che l'autorizzazione protegge. La descrizione è composta da un paio di frasi che descrivono ciò che l'autorizzazione consente a un proprietario. 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 cose che possono andare storti se viene concessa l'autorizzazione a un'app.

Di seguito è riportato 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>

Creare 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, puoi impostare 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 presentate all'utente. L'elemento <permission-group> non specifica le autorizzazioni appartenenti 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.

Consigli personalizzati sulle autorizzazioni

Puoi definire autorizzazioni personalizzate per le tue app e richiedere autorizzazioni personalizzate da altre app definendo elementi <uses-permission>. Tuttavia, valuta attentamente se è necessario farlo.

  • Se stai progettando una suite di app che si espongono l'una all'altra funzionalità, 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, è consigliabile definire ogni autorizzazione una sola volta.
  • Se la funzionalità è disponibile solo per le app firmate con la stessa firma dell'app che lo fornisce, potresti evitare di definire autorizzazioni personalizzate utilizzando i controlli della firma. Quando una delle tue app richiede un'altra delle tue app, la seconda app può verificare che entrambe siano firmate con lo stesso certificato prima di rispettare la richiesta.

Se è necessaria un'autorizzazione personalizzata, valuta se l'accesso deve essere eseguito solo dalle applicazioni firmate dallo stesso sviluppatore dell'applicazione che esegue il controllo delle autorizzazioni, ad esempio durante l'implementazione di comunicazioni sicure tra processi tra due applicazioni dello stesso sviluppatore. In tal caso, consigliamo di utilizzare le autorizzazioni per la firma. Le autorizzazioni della firma sono trasparenti per l'utente ed evitano le autorizzazioni confermate dall'utente, 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.

Ti potrebbero interessare anche:

Panoramica sulla sicurezza di Android
Una discussione dettagliata sul modello di sicurezza della piattaforma Android.