Definisci un'autorizzazione app personalizzata

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.

Avviso: attributo sharedUserId in AndroidManifest.xml <manifest> del file per ogni pacchetto può essere utilizzato avere più pacchetti assegnati allo stesso ID utente. Tuttavia, gli ID utente condivisi causano un comportamento non deterministico all'interno del pacchetto responsabile. Di conseguenza, il loro utilizzo è vivamente sconsigliato e potrebbe essere rimosso in la versione futura di Android. Le app dovrebbero invece usare una comunicazione adeguata come i fornitori di servizi e contenuti, per agevolare e l'interoperabilità tra componenti condivisi. Tieni presente che le app esistenti non possono rimuovi questo valore perché la migrazione da un ID utente condiviso non è supportata.

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.