Implementare la sicurezza

Il team per la sicurezza di Android riceve regolarmente richieste di informazioni su come prevenire potenziali problemi di sicurezza sui dispositivi Android. Inoltre, di tanto in tanto verifichiamo i dispositivi e informiamo i produttori e i partner interessati di potenziali problemi.

Questa pagina fornisce best practice per la sicurezza basate sulle nostre esperienze, ampliando la documentazione Designing for Security (Progettazione per la sicurezza) che abbiamo fornito agli sviluppatori e include dettagli specifici per la creazione o l'installazione di software a livello di sistema sui dispositivi.

Per facilitare l'adozione di queste best practice, ove possibile il team di sicurezza di Android incorpora i test nella Compatibility Test Suite (CTS) e in Android Lint. Invitiamo gli implementatori di dispositivi a contribuire con test che possono aiutare altri utenti Android (visualizza i test relativi alla sicurezza all'indirizzo root/cts/tests/tests/security/src/android/security/cts).

Processo di sviluppo

Utilizza le best practice riportate di seguito nelle tue procedure e nel tuo ambiente di sviluppo.

Esamina il codice sorgente

La revisione del codice sorgente può rilevare una vasta gamma di problemi di sicurezza, inclusi quelli identificati in questo documento. Android incoraggia vivamente la revisione del codice sorgente sia manuale che automatica. Best practice

• Esegui Android Lint su tutto il codice dell'app utilizzando l'SDK Android e correggi eventuali problemi identificati.
• Il codice nativo deve essere analizzato utilizzando uno strumento automatico in grado di rilevare problemi di gestione della memoria come overflow del buffer ed errori di tipo off-by-one.
• Il sistema di compilazione di Android supporta molti dei programmi di sanitizzazione LLVM, come AddressSanitizer e UndefinedBehaviorSanitizer, che possono essere utilizzati per questo scopo.

Utilizzare i test automatici

I test automatici possono rilevare una vasta gamma di problemi di sicurezza, tra cui diversi problemi descritti di seguito. Best practice

• CTS viene aggiornato regolarmente con test di sicurezza. Esegui la versione più recente di CTS per verificare la compatibilità.
• Esegui regolarmente CTS durante il processo di sviluppo per rilevare tempestivamente i problemi e ridurre i tempi di correzione. Android utilizza CTS nell'ambito dell'integrazione continua nel nostro processo di compilazione automatica, che esegue build più volte al giorno.
• I produttori di dispositivi devono automatizzare i test di sicurezza delle interfacce, inclusi i test con input non formattati (fuzz test).

Immagini di sistemi di segnaletica

La firma dell'immagine di sistema è fondamentale per determinare l'integrità del dispositivo. Best practice

• I dispositivi non devono essere firmati con una chiave nota pubblicamente.
• Le chiavi utilizzate per firmare i dispositivi devono essere gestite in modo coerente con le pratiche standard di settore per la gestione delle chiavi sensibili, incluso un modulo di sicurezza hardware (HSM) che fornisce accesso limitato e verificabile.

Firmare le app (APK)

Le firme delle app svolgono un ruolo importante nella sicurezza del dispositivo e vengono utilizzate per i controlli delle autorizzazioni e per gli aggiornamenti del software. Quando selezioni una chiave da utilizzare per la firma delle app, è importante valutare se un'app sarà disponibile solo su un singolo dispositivo o comune a più dispositivi. Best practice

• Le app non devono essere firmate con una chiave nota pubblicamente.
• Le chiavi utilizzate per firmare le app devono essere gestite in modo coerente con le pratiche standard del settore per la gestione delle chiavi sensibili, incluso un HSM che fornisce accesso limitato e verificabile.
• Le app non devono essere firmate con la chiave della piattaforma.
• Le app con lo stesso nome del pacchetto non devono essere firmate con chiavi diverse. Questo accade spesso quando si crea un'app per diversi dispositivi, in particolare quando si utilizza la chiave della piattaforma. Se l'app è indipendente dal dispositivo, utilizza la stessa chiave su tutti i dispositivi. Se l'app è specifica per il dispositivo, crea nomi di pacchetti univoci per dispositivo e chiave.

Pubblicare app

Google Play offre ai produttori di dispositivi la possibilità di aggiornare le app senza eseguire un aggiornamento di sistema completo. In questo modo, puoi accelerare la risposta ai problemi di sicurezza e il rilascio di nuove funzionalità, nonché garantire che la tua app abbia un nome pacchetto univoco. Best practice

• Carica le tue app su Google Play per consentire gli aggiornamenti automatici senza dover eseguire un aggiornamento OTA (over-the-air) completo. Le app caricate ma non pubblicate non sono scaricabili direttamente dagli utenti, ma vengono comunque aggiornate. Gli utenti che hanno già installato l'app possono reinstallarla e/o installarla su altri dispositivi.
• Crea un nome del pacchetto dell'app chiaramente associato alla tua azienda, ad esempio utilizzando il marchio dell'azienda.
• Le app pubblicate dai produttori di dispositivi devono essere caricate sul Google Play Store per evitare il furto d'identità del nome del pacchetto da parte di utenti di terze parti. Se un produttore di dispositivi installa un'app su un dispositivo senza pubblicarla sul Play Store, un altro sviluppatore potrebbe caricare la stessa app, utilizzare lo stesso nome del pacchetto e modificare i metadati dell'app. Quando l'app viene presentata all'utente, questi metadati non correlati potrebbero creare confusione.

Rispondere agli incidenti

Le parti esterne devono essere in grado di contattare i produttori di dispositivi in merito a problemi di sicurezza specifici del dispositivo. Ti consigliamo di creare un indirizzo email accessibile pubblicamente per gestire gli incidenti di sicurezza. Best practice

• Crea un indirizzo security@azienda.it o simile e comunicatelo.
• Se vieni a conoscenza di un problema di sicurezza che interessa il sistema operativo Android o dispositivi Android di più produttori, devi contattare il team di sicurezza di Android inviando un report di bug sulla sicurezza.

Implementare i prodotti

Utilizza le seguenti best practice per l'implementazione di un prodotto.

Isolare i processi di root

I processi di root sono il bersaglio più frequente degli attacchi di escalation dei privilegi, pertanto ridurre il numero di processi di root riduce il rischio di escalation dei privilegi. CTS include un test informativo che elenca i processi principali. Best practice

• I dispositivi devono eseguire il codice minimo necessario come utente root. Se possibile, utilizza un normale processo Android anziché un processo di root. Il Galaxy Nexus con ICS ha solo sei processi di root: vold, inetd, zygote, tf_daemon, ueventd e init. Se un processo deve essere eseguito come root su un dispositivo, documentalo in una richiesta di funzionalità AOSP in modo che possa essere esaminato pubblicamente.
• Ove possibile, il codice principale deve essere isolato dai dati non attendibili e acceduto tramite IPC. Ad esempio, riduci la funzionalità di root a un piccolo servizio accessibile tramite Binder ed esponi il servizio con autorizzazione di firma a un'app con privilegi ridotti o nulli per gestire il traffico di rete.
• I processi di root non devono ascoltare su una socket di rete.
• I processi di root non devono fornire un runtime generico per le app (ad esempio una VM Java).

Isolare le app di sistema

In genere, le app preinstallate non devono essere eseguite con l'UID di sistema condiviso. Tuttavia, se è necessario che un'app utilizzi l'UID condiviso del sistema o di un altro servizio privilegiato, l'app non deve esportare servizi, ricevitori di trasmissione o fornitori di contenuti a cui è possibile accedere tramite app di terze parti installate dagli utenti. Best practice

• I dispositivi devono eseguire il codice minimo necessario come sistema. Se possibile, utilizza un processo Android con il proprio UID anziché riutilizzare l'UID di sistema.
• Ove possibile, il codice di sistema deve essere isolato dai dati non attendibili e deve esporre l'IPC solo ad altri processi attendibili.
• I processi di sistema non devono ascoltare su una socket di rete.

Isolare i processi

La sandbox delle app per Android garantisce alle app un'isolamento da altri processi del sistema, inclusi i processi di root e i debugger. A meno che il debug non sia attivato specificamente dall'app e dall'utente, nessuna app dovrebbe violare questa aspettativa. Best practice

• I processi di root non devono accedere ai dati all'interno delle singole cartelle dei dati delle app, a meno che non venga utilizzato un metodo di debug di Android documentato.
• I processi di root non devono accedere alla memoria delle app, a meno che non venga utilizzato un metodo di debug di Android documentato.
• I dispositivi non devono includere app che accedono ai dati o alla memoria di altre app o procedure.

File SUID protetti

I nuovi programmi setuid non devono essere accessibili da programmi non attendibili. I programmi setuid spesso contengono vulnerabilità che possono essere utilizzate per ottenere l'accesso come utente root, quindi cerca di ridurre al minimo la disponibilità del programma setuid per le app non attendibili. Best practice

• I processi SUID non devono fornire una shell o una backdoor che possa essere utilizzata per aggirare il modello di sicurezza di Android.
• I programmi SUID non devono essere scrivibili da nessun utente.
• I programmi SUID non devono essere leggibili o eseguibili da tutti. Crea un gruppo, limita l'accesso al file binario SUID ai membri del gruppo e inserisci in questo gruppo tutte le app che devono essere in grado di eseguire il programma SUID.
• I programmi SUID sono una fonte comune di rooting dei dispositivi da parte degli utenti. Per ridurre questo rischio, i programmi SUID non devono essere eseguibili dall'utente della shell.

Il verificatore CTS include un test informativo che elenca i file SUID; alcuni file setuid non sono consentiti dai test CTS.

Socket di ascolto sicuri

I test CTS non superano quando un dispositivo è in ascolto su qualsiasi porta, su qualsiasi interfaccia. In caso di errore, Android verifica che vengano utilizzate le seguenti best practice:

• Sul dispositivo non devono essere presenti porte di ascolto.
• Le porte di ascolto devono essere disattivabili senza OTA. Può trattarsi di una modifica della configurazione del server o del dispositivo dell'utente.
• I processi di root non devono rimanere in ascolto su nessuna porta.
• I processi di proprietà dell'UID di sistema non devono rimanere in ascolto su nessuna porta.
• Per l'IPC locale che utilizza le socket, le app devono utilizzare una socket di dominio UNIX con accesso limitato a un gruppo. Crea un descrittore di file per l'IPC e impostalo su +RW per un gruppo UNIX specifico. Tutte le app client devono appartenere al gruppo UNIX.
• Alcuni dispositivi con più processori (ad es. un'unità radio/modem separata dal processore dell'app) utilizzano socket di rete per comunicare tra i processori. In questi casi, la porta di rete utilizzata per la comunicazione tra i processori deve utilizzare un'interfaccia di rete isolata per impedire l'accesso da parte di app non autorizzate sul dispositivo (ovvero utilizzare iptables per impedire l'accesso da parte di altre app sul dispositivo).
• I demoni che gestiscono le porte di ascolto devono essere resistenti ai dati non formattati. Google potrebbe eseguire test di fuzz sulla porta utilizzando un client non autorizzato e, se possibile, un client autorizzato. Eventuali arresti anomali vengono registrati come bug con una gravità appropriata.

Dati di log

La registrazione dei dati aumenta il rischio di esposizione di questi dati e riduce le prestazioni del sistema. Si sono verificati diversi incidenti di sicurezza pubblica a seguito della registrazione di dati utente sensibili da parte di app installate per impostazione predefinita sui dispositivi Android. Best practice

• Le app o i servizi di sistema non devono registrare i dati forniti da app di terze parti che potrebbero includere informazioni sensibili.
• Le app non devono registrare informazioni che consentono l'identificazione personale (PII) nell'ambito del normale funzionamento.

CTS include test che verificano la presenza di informazioni potenzialmente sensibili nei log di sistema.

Limita l'accesso alla directory

Le directory con accesso in scrittura da parte di tutti gli utenti possono introdurre debolezze di sicurezza e consentire a un'app di rinominare file attendibili, sostituire file o eseguire attacchi basati su link simbolici (gli utenti malintenzionati possono utilizzare un link simbolico a un file per indurre un programma attendibile a eseguire azioni non consentite). Le directory scrivibili possono anche impedire la pulizia corretta di tutti i file associati a un'app durante la disinstallazione.

Come buona prassi, le directory create dall'utente root o dal sistema non devono essere scrivibili da tutti. I test CTS contribuiscono a applicare questa best practice testando le directory conosciute.

File di configurazione sicuri

Molti driver e servizi si basano su file di configurazione e dati archiviati in directory come /system/etc e /data. Se questi file vengono elaborati da un processo privilegiato e sono scrivibili da tutti, è possibile per un'app sfruttare una vulnerabilità nel processo creando contenuti dannosi nel file scrivibile da tutti. Best practice

• I file di configurazione utilizzati da processi con privilegi non devono essere accessibili a tutti.
• I file di configurazione utilizzati dai processi con privilegi non devono essere scritti da tutti.

Memorizzare le librerie di codice nativo

Qualsiasi codice utilizzato dai processi privilegiati del produttore del dispositivo deve trovarsi in /vendor o /system; questi file system vengono montati in sola lettura all'avvio. Come best practice, anche le librerie utilizzate dal sistema o da altre app con privilegi elevati installate sul dispositivo devono trovarsi in questi filesystem. In questo modo è possibile evitare una vulnerabilità di sicurezza che potrebbe consentire a un malintenzionato di controllare il codice eseguito da un processo con privilegi.

Limita l'accesso del driver del dispositivo

Solo il codice attendibile deve avere accesso diretto ai driver. Ove possibile, l'architettura preferita è fornire un daemon a scopo unico che esegui proxy per le chiamate al driver e limita l'accesso del driver a quel daemon. Come best practice, i nodi dei dispositivi del driver non devono essere leggibili o scrivibili da tutti. I test CTS contribuiscono a applicare questa best practice controllando la presenza di istanze note di driver esposti.

Disattivare ADB

Android Debug Bridge (adb) è uno strumento prezioso per lo sviluppo e il debug, ma è progettato per essere utilizzato in ambienti controllati e sicuri e non deve essere attivato per l'uso generale. Best practice

• ADB deve essere disattivato per impostazione predefinita.
• ADB deve richiedere all'utente di attivarlo prima di accettare le connessioni.

Sbloccare i bootloader

Molti dispositivi Android supportano lo sblocco, consentendo al proprietario del dispositivo di modificare la partizione di sistema e/o installare un sistema operativo personalizzato. I casi d'uso comuni includono l'installazione di una ROM di terze parti e lo sviluppo a livello di sistema sul dispositivo. Ad esempio, il proprietario di un dispositivo Google Nexus può eseguire fastboot oem unlock per avviare la procedura di sblocco, che presenta all'utente il seguente messaggio:

Come best practice, i dispositivi Android sbloccabili devono cancellare in modo sicuro tutti i dati dell'utente prima di essere sbloccati. La mancata eliminazione corretta di tutti i dati al momento dello sblocco potrebbe consentire a un malintenzionato fisicamente vicino di ottenere l'accesso non autorizzato ai dati utente riservati di Android. Per impedire la divulgazione dei dati utente, un dispositivo che supporta lo sblocco deve implementarlo correttamente (abbiamo riscontrato numerosi casi in cui i produttori di dispositivi hanno implementato in modo improprio lo sblocco). Un procedura di sblocco implementata correttamente ha le seguenti proprietà:

• Quando il comando di sblocco viene confermato dall'utente, il dispositivo deve avviare immediatamente un reset dei dati. Il flag unlocked non deve essere impostato fino al completamento dell'eliminazione sicura.
• Se non è possibile completare un'eliminazione sicura, il dispositivo deve rimanere in stato bloccato.
• Se supportato dal dispositivo di blocco sottostante, deve essere utilizzato ioctl(BLKSECDISCARD) o un valore equivalente. Per i dispositivi eMMC, significa utilizzare un comando Secure Erase o Secure Trim. Per eMMC 4.5 e versioni successive, significa utilizzare una normale operazione di cancellazione o ridimensionamento seguita da un'operazione di pulizia.
• Se BLKSECDISCARD non è supportato dal dispositivo di blocco di base, deve essere utilizzato ioctl(BLKDISCARD). Sui dispositivi eMMC, si tratta di un'operazione di Trim normale.
• Se BLKDISCARD non è supportato, è accettabile sovrascrivere i dispositivi di blocco con tutti gli zeri.
• Un utente finale deve avere la possibilità di richiedere l'eliminazione dei dati utente prima di eseguire il flashing di una partizione. Ad esempio, sui dispositivi Nexus, questo viene fatto tramite il comando fastboot oem lock.
• Un dispositivo potrebbe registrare, tramite efuse o un meccanismo simile, se è stato sbloccato e/o bloccato di nuovo.

Questi requisiti garantiscono che tutti i dati vengano distrutti al termine di un'operazione di sblocco. La mancata implementazione di queste protezioni è considerata una vulnerabilità di sicurezza di livello moderato.

Un dispositivo sbloccato può essere successivamente bloccato di nuovo utilizzando il comandofastboot oem lock. Il blocco del bootloader offre la stessa protezione dei dati utente con il nuovo sistema operativo personalizzato che era disponibile con il sistema operativo del produttore del dispositivo originale (ad esempio, i dati utente verranno cancellati se il dispositivo viene nuovamente sbloccato).