La piattaforma Android sfrutta la protezione basata sull'utente Linux per identificare e isolare le risorse dell'app. Questo isola le app l'una dall'altra e protegge le app e il sistema da app dannose. Per fare ciò, Android assegna un ID utente univoco (UID) a ciascuna applicazione Android e la esegue nel proprio processo.
Android usa l'UID per configurare una sandbox dell'applicazione a livello di kernel. Il kernel applica la sicurezza tra le app e il sistema a livello di processo attraverso strutture Linux standard come ID utente e gruppo assegnati alle app. Per impostazione predefinita, le app non possono interagire tra loro e hanno un accesso limitato al sistema operativo. Se l'app A tenta di fare qualcosa di dannoso, come leggere i dati dell'applicazione B o chiamare il telefono senza autorizzazione, non può farlo perché non dispone dei privilegi utente predefiniti appropriati. La sandbox è semplice, controllabile e basata su decenni di separazione degli utenti in stile UNIX di processi e autorizzazioni di file.
Poiché l'Application Sandbox è nel kernel, questo modello di sicurezza si estende sia al codice nativo che alle applicazioni del sistema operativo. Tutto il software sopra il kernel, come librerie del sistema operativo, framework dell'applicazione, runtime dell'applicazione e tutte le applicazioni, viene eseguito all'interno dell'Application Sandbox. Su alcune piattaforme, gli sviluppatori sono vincolati a un framework di sviluppo, a un set di API o a un linguaggio specifico. Su Android, non ci sono restrizioni su come è possibile scrivere un'applicazione necessarie per rafforzare la sicurezza; a questo proposito, il codice nativo è sandbox come il codice interpretato.
Protezioni
In genere, per uscire dall'Application Sandbox in un dispositivo correttamente configurato, è necessario compromettere la sicurezza del kernel Linux. Tuttavia, analogamente ad altre funzionalità di sicurezza, le protezioni individuali che applicano la sandbox dell'applicazione non sono invulnerabili, quindi una difesa approfondita è importante per evitare che singole vulnerabilità comportino la compromissione del sistema operativo o di altre app.
Android si basa su una serie di protezioni per applicare la sandbox dell'applicazione. Queste imposizioni sono state introdotte nel tempo e hanno notevolmente rafforzato la sandbox DAC (Discretional Access Control) originale basata su UID. Le versioni precedenti di Android includevano le seguenti protezioni:
- In Android 5.0, SELinux prevedeva la separazione obbligatoria del controllo di accesso (MAC) tra il sistema e le app. Tuttavia, tutte le app di terze parti sono state eseguite all'interno dello stesso contesto SELinux, quindi l'isolamento tra le app è stato applicato principalmente dall'UID DAC.
- In Android 6.0, la sandbox SELinux è stata estesa per isolare le app oltre il limite per utente fisico. Inoltre, Android ha anche impostato impostazioni predefinite più sicure per i dati delle applicazioni: per le app con
targetSdkVersion >= 24
, le autorizzazioni DAC predefinite sulla directory home di un'app sono state modificate da 751 a 700. Ciò ha fornito impostazioni predefinite più sicure per i dati delle app private (sebbene le app possano sovrascrivere queste impostazioni predefinite) . - In Android 8.0, tutte le app erano impostate per essere eseguite con un filtro
seccomp-bpf
che limitava le chiamate di sistema che le app potevano utilizzare, rafforzando così il confine app/kernel. - In Android 9 tutte le app non privilegiate con
targetSdkVersion >= 28
devono essere eseguite in singole sandbox SELinux, fornendo MAC in base all'app. Questa protezione migliora la separazione delle app, impedisce l'override delle impostazioni predefinite sicure e (soprattutto) impedisce alle app di rendere accessibile il loro mondo di dati. - In Android 10 le app hanno una vista grezza limitata del filesystem, senza accesso diretto a percorsi come /sdcard/DCIM. Tuttavia, le app mantengono l'accesso non elaborato completo ai percorsi specifici del pacchetto, come restituito da qualsiasi metodo applicabile, ad esempio Context.getExternalFilesDir() .
Linee guida per la condivisione di file
Impostare i dati delle app come accessibili al mondo è una pratica di sicurezza scadente. L'accesso è concesso a tutti e non è possibile limitare l'accesso ai soli destinatari previsti. Questa pratica ha portato a perdite di divulgazione di informazioni e vulnerabilità confuse dei vice ed è uno degli obiettivi preferiti per il malware che prende di mira le app con dati sensibili (come i client di posta elettronica). In Android 9 e versioni successive, la condivisione di file in questo modo non è esplicitamente consentita per le app con targetSdkVersion>=28
.
Invece di rendere i dati dell'app accessibili in tutto il mondo, utilizzare le seguenti linee guida durante la condivisione dei file:
- Se la tua app deve condividere file con un'altra app, usa un provider di contenuti . I fornitori di contenuti condividono i dati con la granularità adeguata e senza i molti aspetti negativi delle autorizzazioni UNIX accessibili in tutto il mondo (per i dettagli, fare riferimento a Nozioni di base sui fornitori di contenuti ).
- Se la tua app contiene file che in realtà dovrebbero essere accessibili al mondo intero (come foto), devono essere specifici per i media (solo foto, video e file audio) e archiviati utilizzando la classe MediaStore . (Per ulteriori dettagli su come aggiungere un elemento multimediale, vedere Accesso ai file multimediali dall'archivio condiviso .)
L'autorizzazione di runtime di archiviazione controlla l'accesso alle raccolte fortemente tipizzate tramite MediaStore . Per accedere a file con tipizzazione debole come PDF e la classe MediaStore.Downloads , le app devono utilizzare intenti come ACTION_OPEN_DOCUMENT .
Per abilitare il comportamento di Android 10, usa l'attributo manifest requestLegacyExternalStorage
e segui le best practice per le autorizzazioni dell'app .
- Il valore predefinito del flag manifest è
true
per le app destinate ad Android 9 (e versioni precedenti). - Il valore predefinito è false per le app destinate ad Android 10. Per disattivare temporaneamente la visualizzazione dello spazio di archiviazione filtrato nelle app destinate ad Android 10, imposta il valore del flag manifest su
true
. - Utilizzando autorizzazioni limitate, il programma di installazione inserisce nella whitelist le app consentite per l'archiviazione non sandbox. Le app non autorizzate sono in modalità sandbox.