Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola Sicurezza e Permission in Android

Transcript

1 Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola Sicurezza e Permission in Android

2 La sicurezza al giorno d oggi è uno degli aspetti più importanti dell informatica! E tenere conto della sicurezza durante la realizzazione degli applicativi è diventato non solo un dovere, ma un obbligo. Che cosa si intende per Sicurezza informatica? Con il termine sicurezza informatica si intende quel ramo che si occupa dell'analisi delle vulnerabilità, del rischio, delle minacce e attacchi di un sistema informatico e dei dati in esso contenuti o scambiati in una comunicazione con uno più applicazioni. Ma il concetto di sicurezza può avere molteplici significati, in relazione al compito che si sta svolgendo; gli esempi più conosciuti riguardano il non permettere a un applicazione l esecuzione di operazioni che potrebbero essere sensibili, come l accesso ai dati personali, a risorse locali, oppure aprire connessioni o iniziare telefonate senza la diretta richiesta da parte dell utente. Quindi un metodo per garantire la sicurezza potrebbe essere l utilizzo di opportuni permessi e richiedendo eventualmente l accesso all utente con adeguate notifiche. Questi ultimi due aspetti saranno introdotti in questa tesina. System Permissions in Android Android è un sistema operativo che considera i privilegi separati, ciò significa che ogni applicazione esegue con un distinto sistema di identificazione (Linux user ID e group ID), dove parti del sistema sono separate in distinte identità. Linux infatti isola le applicazioni da ogni altra e dal sistema stesso. Altre funzioni di sicurezza dettagliate sono previste grazie alle permission, cioè dei meccanismi che forzano la restrizioni sulle specifiche operazioni che un particolare processo può eseguire. Architettura della sicurezza Un punto centrale sulla sicurezza nelle architetture di Android è che nessuna applicazione, per default, ha il permesso di eseguire qualsiasi operazione che avrebbe un impatto negativo su altre applicazioni o sul sistema o sull utente. Questo perché ogni applicazione Android deve esplicitamente condividere risorse e dati, dichiarando i permessi che necessitano per utilizzare capacità aggiuntive non previste di base. Gestione dei permission Si tratta di una modalità con cui una particolare applicazione dichiara e richiede l utilizzo di una funzionalità esterna all applicazione o con dati sensibili. Un esempio potrebbe essere che l applicativo necessita di accedere alla Rubrica, oppure ad utilizzare l hardware GPS. Tale richiesta viene denominata Permission. Gli stessi comportamenti dovranno essere seguiti nella volontà di accedere alla rete o di attivare la fotocamera o di inviare un semplice messaggio. Come primo procedimento occorre implementare il relativo Permission nel file AndroidManifest.xml, presente per default in ogni applicativo sviluppato in Android.

3 Occorre, comunque, che al livello di runtime dell esecuzione dell app l utente esprima il consenso a tale utilizzo. In relazione poi alla tipologia di Permission adottata, tale richiesta può essere effettuata solo la prima volta o ogni volta che l applicativo ne richieda l accesso. Nel caso in cui l operazione non venga approvata dall utente viene sollevata una SecurityException, a meno che non si tratti di un BroadcastReceiver, per il quale viene solamente visualizzato un messaggio di log. Esistono Permission definite dall ambiente Android e altre che è possibile definire in modo personalizzato. In questa tesina presentiamo entrambi i casi, ma per una lettura più dettagliata ed un elenco completo si può fare riferimento alla classe android.manifest.permission presente in ogni documento specializzato. Ciascun permesso viene descritto da un nome del tipo: android.permission.<related_permission> e specificato nel documento AndroidManifest.xml attraverso l utilizzo dell elemento <usespermission>. Un esempio viene presentato nella figura seguente: Come si può notare l elemento <uses-permission> è figlio dell elemento radice <manifest>. Se tali permessi non vengono esplicitati nel precedente file, all esecuzione dell applicativo viene generato un errore.

4 Normal and Dangerous Permissions Il sistema dei permessi è diviso in diversi livelli di protezione. I principali sono normal e dangerous permissions: - I Normal permissions coprono un area dove la tua applicazione necessita di accedere a dati o risorse fuori dal sandbox, ma dove vi è solo un piccolo rischio a discapito della privacy dell utente o delle operazioni delle altre apps. - I Dangerous permissions coprono aree dove l applicazione richiede dati o risorse che coinvolgono le informazioni private dell utente, o potrebbero potenzialmente influenzare la gestione dei dati e le operazioni delle altre apps. In questo caso, quando un applicativo richiede permessi in tale categoria, l utente deve esplicitamente garantire il permesso di accesso. (Un semplice esempio è l abilità di leggere i contatti dell utente). Permission groups Tutti i Dangerous permissions appartengono al rispettivo gruppo. Se il dispositivo che sta eseguendo l applicativo ha una versione di Android 6.0 (API level 23) e la versione è la 23 o superiore, il seguente comportamento del sistema vale per tutte le richieste di permessi pericolosi: - Se un applicazione richiede un dangerous permission nel suo manifest, e l applicazione al momento non ha alcuna autorizzazione nel permission group, il sistema mostra un dialog box all utente, descrivendo il permesso che si desidera. Successivamente verrà inserito nel permission group nel caso in cui l utente approvi, per una possibile richiesta futura. - Se un applicazione richiede un dangerous permission nel suo manifest e ha già un altro dangerous permissione nello stesso permission group, il sistema immediatamente garantisce il permesso senza l interazione con l utente, senza perciò la visualizzazione della richiesta. Questo avviene se, per esempio, un app ha già richiesto tale autorizzazione. In realtà, qualunque permesso appartiene a un permission group, includendo perciò anche i normal permission ed i permessi definiti nella mia app (argomento trattata nel paragrafo sotto). Comunque gli effetti dati dall utilizzo di tali permessi ha risentimento solo per quelli considerati dangerous. E possibile perciò ignorare i permission group dei normal permissions

5 Creazione di Permission personalizzate E possibile definire nuove Permission al fine di limitare l accesso a determinate operazioni o l utilizzo di particolari componenti. Anche in questo caso il primo passo da svolgere è la definizione dei permissions nell AndroidManifest.xml utilizzando la nomenclatura <permission>. A tal proposito viene rilasciata un apposita interfaccia ADT che permette la definizione delle informazioni relative alla sicurezza attraverso il corrispondente tab nell editor del manifest. L elemento Permission prevede una serie di attributi, tra i quali il nome del permission, che impiega la seguente conversione: <name application package>.permission.<permission_name> concatenando il nome del package e il nome del permesso con lettere maiuscole. Altri attributi da menzionare riguardano il Protection Level ed il Permission Group. Il primo permette di specificare come si dovrà comportare il sistema al momento dell installazione, per richiedere eventualmente consensi all utente. Il valore di default di questo campo è normal e indica un consenso automatico da parte del sistema, comunque visualizzato dall utente durante l installazione, in modo da garantire una possibile interruzione dell operazione. Differente invece è l utilizzo del valore dangerous, nella quale il sistema chiede sempre conferma esplicita all utente all atto dell installazione. Infine il valore signature, valido solo per le applicazioni che presentano la stessa firma di certificato. Termine molto simile è signatureorsystem nella quale oltre alla precedente condizione viene aggiunto lo specifico utilizzo degli applicativi di sistema. Quest ultimo viene molto utilizzato dagli sviluppatori software delle grandi aziende, in modo da garantire un vantaggio alle loro stesse applicazioni. L informazione relativa al Permission Group serve semplicemente per raggruppare i permessi derivanti dalla stessa famiglia. Per concludere possiamo indicare i campi label e description che dovrebbero essere forniti per visualizzare su display quando gli utenti stanno controllando la lista dei permessi o i dettagli di un singolo permesso. Un consiglio di buona programmazione indica che i label devono essere corti, un paio di parole per descrivere il suo utilizzo. Mentre description rappresentano un paio di frasi che descrivono che cosa il permesso permette di fare. La convenzione di Android prevede il description con due frasi.