Mobile OSs analysis

Mobile OSs analysis
Report for the Computer Security exam at the Politecnico di Torino
Alessio Canepa (207687)
Andrea Marcelli (209051)
tutor: Andrea Atzeni
June 2015
1
Indice
1 Introduzione
6
1.1
Il mercato dei dispositivi mobili . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2
Il problema della sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.1
Differenze tra sicurezza su mobile e su fisso . . . . . . . . . . . . . . . . .
7
1.2.2
Obiettivi di un attacco . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2.3
Canali di attacco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.4
Esempio di malware: SimpLocker, un ransomware per Android . . . . . . 10
1.2.5
Proteggersi dagli attacchi . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3
Il modello dell’analisi di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4
Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Ubuntu Touch
17
2.1
Modalità dell’analisi di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3
2.2.1
Poca integrazione tra S.O. mobili e fissi . . . . . . . . . . . . . . . . . . . 18
2.2.2
Convergenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1
LXC - Linux Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2
Mir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3
Unity 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4
Applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4
Modello di sicurezza del sistema operativo . . . . . . . . . . . . . . . . . . . . . 23
2.5
Tecniche di confinamento delle applicazioni . . . . . . . . . . . . . . . . . . . . . 23
2.6
2.5.1
La necessità di confinare le applicazioni in Ubuntu . . . . . . . . . . . . . 23
2.5.2
Introduzione ad AppArmor . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.3
AppArmor profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.4
Policy Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.5
Gestione autorizzazioni: Trusted Helpers . . . . . . . . . . . . . . . . . . 28
2.5.6
Condivisione contenuti: Content Hub . . . . . . . . . . . . . . . . . . . . 29
Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.1
Creazione e firma digitale delle applicazioni . . . . . . . . . . . . . . . . 31
2.6.2
Upload, controllo e firma digitale dello store . . . . . . . . . . . . . . . . 32
2.6.3
Download e verifica della firma digitale . . . . . . . . . . . . . . . . . . . 32
2
2.7
2.8
2.9
Memorizzazione dati critici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.1
GNOME Keyring e AppArmor . . . . . . . . . . . . . . . . . . . . . . . 33
2.7.2
Credenziali web: Ubuntu online accounts . . . . . . . . . . . . . . . . . . 33
Cifratura dati utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.1
Introduzione a eCryptfs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.2
Funzionamento di eCryptfs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Protezione dell’accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.10 Altri elementi di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10.1 GSettings/dconf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10.2 Display manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.10.3 Environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.10.4 Segnali tra processi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.10.5 Protezione da remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.10.6 Certificati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.11 Vulnerabilità note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.12 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 CyanogenMod
40
3.1
Modalità dell’analisi di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3
3.2.1
Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2
Differenze con Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.3
Distribuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.4
Device Rooted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Tecniche di confinamento delle applicazioni . . . . . . . . . . . . . . . . . . . . . 42
3.3.1
Il modello Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2
Gestione dei permessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.3
Gestione privilegi di root . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4
Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5
Componenti di sicurezza aggiuntivi . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.1
Whisperpush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5.2
Protezione da remoto: Device Finder . . . . . . . . . . . . . . . . . . . . 46
3.6
Cifratura dati utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.7
Protezione dell’accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.8
Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3
4 Tizen
51
4.1
Modalità dell’analisi di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3
4.4
4.5
4.2.1
Tizen, “The OS of Everything” . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2
Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.3
Le architetture supportate . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.4
Le applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.5
Strumenti di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1
Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.2
Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.3
Framework Nativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.4
Framework Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.5
Web Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Modello di sicurezza del sistema operativo . . . . . . . . . . . . . . . . . . . . . 56
4.4.1
L’utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.2
Le applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.3
Il sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.4
I principali componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Tecniche di confinamento delle applicazioni . . . . . . . . . . . . . . . . . . . . . 59
4.5.1
Smack - Simplified Mandatory Access Control Kernel . . . . . . . . . . . 59
4.5.2
Smack in Tizen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.3
UserID e GroupID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.4
The three domain model . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5.5
Cynara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.6
Commenti sul modello del controllo degli accessi in Tizen . . . . . . . . . 66
4.5.7
Il sistema dei privilegi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.5.8
Firma delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5.9
Installazione delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . 70
4.5.10 Esecuzione delle applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5.11 Vasum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6
4.7
Criticità progettuali ed implementative delle applicazioni . . . . . . . . . . . . . 74
4.6.1
Conversione automatica della applicazioni . . . . . . . . . . . . . . . . . 74
4.6.2
WebGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6.3
XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4
4.8
4.7.1
Il processo di revisione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.7.2
Connessione alla Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.7.3
Store non ufficiali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Cifratura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.8.1
4.9
Cifratura applicazioni Web . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Componenti di sicurezza aggiuntivi . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.9.1
Tizen Key Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.9.2
Secure Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.9.3
Content Security and Reputation Framework . . . . . . . . . . . . . . . . 85
4.9.4
Wifi Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.9.5
Gestione dei certificati SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.9.6
Tecniche di mitigazione degli exploit . . . . . . . . . . . . . . . . . . . . 90
4.10 Protezione dell’accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.11 Vulnerabilità note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.12 Analisi Sperimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.12.1 Test Smack label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.12.2 Test ASLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.12.3 Test DEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.13 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5 Conclusioni
96
6 Appendice
100
6.1
Memorizzazione dati critici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.1
6.2
GNOME Keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Sicurezza delle connessioni di rete . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.1
GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.2
WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3
Address Space Layout Randomization . . . . . . . . . . . . . . . . . . . . . . . . 105
6.4
Data Execution Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.5
Modelli per il controllo degli accessi . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.6
6.5.1
Discretionary access control . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.5.2
Mandatory Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . 107
LXC / Linux Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5
1
1.1
Introduzione
Il mercato dei dispositivi mobili
Il vertiginoso sviluppo tecnologico che ha caratterizzato l’ultimo ventennio ha portato diverse
innovazioni, permettendo di lanciare sul mercato numerosi dispositivi innovativi. I progressi
sulla “portabilità” della tecnologia hanno giocato un ruolo essenziale: sono nati nuovi dispositivi
tascabili che hanno permesso di soddisfare la crescente necessità di archiviazione di dati e di
connettività in movimento. Il mercato dei dispositivi mobili, ha reso “portabili” gran parte
delle funzionalità fino a quel momento ristrette ai soli computer desktop, introducendo i nuovi
smartphone, tablet e computer portatili, tutti dotati di caratteristiche necessarie per un costante
utilizzo al di fuori dei tradizionali confini aziendali e domestici.
Considerando i soli dispositivi in grado di connettersi ad internet, il loro numero ha recentemente
superato quello della popolazione mondiale: i dati [1] stimano 7.3 miliardi di dispositivi contro
7.2 miliardi di persone. Di questi più di 1.2 miliardi sono telefoni cellulari e il loro numero è
destinato a crescere, raggiungendo i 4 miliardi nel 2018 [2], con un forte sviluppo del mercato
asiatico, soprattutto in Cina ed India.
Sebbene il termine dispositivo mobile si riferisca ad un insieme di dispositivi molto vasto, come
tecnologie wearable, smartphone, fotocamere ed altri, nel corso del report sarà utilizzato per
indicare solo i telefoni cellulari di ultima generazione (smartphone) ed i tablet.
In modo simile a quanto accade nel mondo desktop, l’interfaccia utente, il supporto per le
applicazioni e tutte le altre funzionalità sono offerte da un sistema operativo. L’importanza
acquisita negli ultimi anni dai dispositivi mobile rende necessario un’approfondita analisi delle
soluzioni di sicurezza adottate dai diversi sistemi. Nelle successive sezioni saranno analizzate
le principali differenze che caratterizzano il mondo mobile dal tradizionale desktop e le relative
implicazioni di sicurezza. Saranno anche introdotti i principali obiettivi e vettori di attacco, le
cui contromisure verrano successivamente analizzate per ciascun sistema operativo trattato.
1.2
Il problema della sicurezza
L’avanzamento tecnologico garantisce ai dispositivi mobili una capacità computazionale sempre
maggiore. Da un lato, combinata con veloci interfacce di connessione, ha reso i dispositivi
mobili bersagli di attacco appetibili per l’utilizzo anche in contesti malevoli, come all’interno di
botnet. Dall’altro, una maggior capacità computazionale, unita alle caratteristiche di “portabilità” e semplicità d’uso, ha contribuito ad offrire maggiori funzionalità agli utenti. Alcune di
queste sono operazioni sensibili per la sicurezza e privacy degli utilizzatori. Ad esempio, molti
dispositivi mobile permettono di eseguire operazioni delicate quali l’esecuzione di movimenti
bancari o la gestione di servizi a pagamento. La loro diffusione ha ampliato enormemente il
panorama degli utilizzatori, estesosi a quasi tutte le fasce di età. Oltre ad un incremento di
utilizzo, si è assistito anche ad un aumento della fiducia nei download di contenuti provenienti
da autori sconosciuti.
A livello applicativo, la semplificazione della procedura di sviluppo, anche tramite l’introduzione di SDK evoluti, ha favorito la crescita delle applicazioni disponibili. Nel primo trimestre
del 2014, i due maggiori store distributori di applicazioni (AppStore e GooglePlay) hanno totalizzato globalmente circa 250 milioni di download. La ricerca di malware nel volume delle
applicazioni esistenti, è difficile.
La sicurezza in ambito mobile è un problema importante, che richiede di essere adeguatamente
affrontato: le previsioni di Infonetics Research prevedono un aumento dei relativi costi, con
6
Figura 1: Numero di minacce contro dispositivi mobili.1
una punta di 3.8 miliardi di dollari nel 2018, da confrontarsi con gli 1.3 miliardi del 2013 [3].
Un ulteriore dato significativo è quello riguardante la crescita di minacce, in particolare quelle
finalizzate all’estorsione di denaro, come mostrato in Figura 1.
1.2.1
Differenze tra sicurezza su mobile e su fisso
La diversità tra i dispositivi mobili ed i calcolatori tradizionali rende difficile la semplice migrazione delle soluzioni di sicurezza già disponibili, richiedendone la progettazione di nuove. Di
seguito sono elencate le differenze tra il mondo mobile e fisso che maggiormente influiscono sul
campo della sicurezza.
• Mobilità: i dispositivi mobili nascono per poter essere sempre trasportati con sé. Se
lasciati incustoditi, sono soggetti a furto o ad accesso non autorizzato: è necessario avere
a disposizione nuovi sistemi per la protezione dell’accesso fisico.
• Connettività: smartphone e tablet supportano varie tecnologie di comunicazione (GSM,
3G/4G, Wi-Fi, Bluetooth, NFC), tutte rappresentano canali per possibili attacchi. Sebbene alcuni siano presenti anche sui sistemi fissi, nel caso dei dispositivi mobili sono
indubbiamente molto più utilizzati, anche quando non necessario. Un esempio sono il
Bluetooth ed il Wi-Fi, che vengono spesso lasciati attivi per comodità.
• Scheda SIM: è necessaria per il funzionamento degli smartphone ed oggi è presente anche
nella maggior parte dei tablet. Alla scheda SIM è associato un credito telefonico, grazie al
quale è possibile usufruire di servizi a pagamento come telefonate, SMS e traffico dati. Se
un attaccante riuscisse a prendere il controllo del dispositivo, potrebbe avere facile accesso
a tali risorse economiche. Secondo alcune ricerche [4], il 50% del malware recente su
mobile funziona in questo modo, essendo relativamente semplice per l’attaccante ottenere
un profitto. Inoltre, poiché dal punto di vista dell’operatore mobile i costi sono addebitati
comunque all’utente finale, è difficile differenziare i casi di sottrazione di denaro illecito
da lecite spese.
1
Sorgente immagine: Mobile Security: Finally a Serious Problem?, Neal Leavitt, IEEE Computer Society,
June 11
7
• Capacità computazionale e batteria: mediamente, smartphone e tablet non dispongono
della stessa capacità computazionale dei calcolatori fissi, soprattutto in termini di CPU e
di disponibilità di memoria RAM. Nonostante i modelli più performanti possano comunque avere caratteristiche hardware confrontabili ad alcuni computer desktop, la scarsa
autonomia della batteria è un altro fattore limitante. In ambito mobile, non è semplice
realizzare protezioni a livello software basate su processi in continua esecuzione e computazionalmente intesivi. Inoltre, questo punto è particolarmente critico, poiché la durata
della batteria è una delle caratteristiche del dispositivo più valutate a livello commerciale.
• Sensori: I dispositivi mobili sono in genere dotati di una vasta gamma di sensori che offrono diversi servizi. Il GPS, la fotocamera, il microfono e l’accelerometro sono i principali.
Qualora un attaccante riuscisse ad aver accesso ai dati dei sensori, avrebbe a disposizione
un’enormità di informazioni per monitorare di nascosto l’utente. Ad esempio, una ricerca
[5] ha dimostrato come sia possibile ottenere i caratteri digitati su una tastiera attraverso
il solo utilizzo dell’accelerometro.
1.2.2
Obiettivi di un attacco
Esistono diversi obiettivi di un attacco da cui utenti e dispositivi devono proteggersi. Di seguito
sono elencati i principali:
• Accesso a dati privati. I dispositivi mobili sono un mezzo di archiviazione di materiale
personale, quindi un bersaglio appetibile per ottenere informazioni private su un utente.
Nel caso di smartphone: SMS, email, il log delle chiamate e dati di alcune applicazioni
sono molto interessanti. Inoltre le informazioni potrebbero anche essere eliminate o modificate. Un esempio è l’applicazione SpyPhone2 , per Android ed iOS, che viene eseguita
in background ed è in grado di fornire ad un utente remoto informazioni relative a SMS,
chiamate, email, inviare fotografie, informazioni di localizzazione, registrare audio ed altre
ancora.
• Furto d’identità. Uno smartphone costituisce indirettamente una forma di autenticazione del suo possessore grazie alle informazioni contenute, al contratto telefonico a cui è
associato ed alle password che memorizza.
• Overbilling. Con questo termine si indicano gli attacchi volti ad utilizzare il credito
telefonico associato ad un dispositivo, ad insaputa dell’utente. Ad esempio, inviando
SMS automaticamente o effettuando chiamate verso numeri a pagamento.
• Estorsione di denaro. In questa categoria rientrano i ransomware, software malevoli
che applicano delle limitazioni nell’utilizzo del dispositivo e successivamente richiedono
il pagamento di un riscatto (ransom in Inglese) per rimuovere il blocco. Un esempio è
SimpLocker [6], un ransomware per Android, responsabile di cifrare alcune file importanti
e di impedire qualsiasi operazione sul dispositivo, reindirizzando l’utente sempre alla
schermata di sblocco. Si rimanda ad un’analisi dettagliata in 1.2.4.
• Lo sfruttamento della capacità computazionale. Nonostante, come precedentemente detto,
la capacità computazionale di un dispositivo mobile non sia attualmente comparabile con
quella di un calcolatore fisso, negli anni si è assistito ad una crescita della velocità della
CPU e della disponibilità di memoria RAM. Combinata con collegamenti internet ad alta
velocità, rende i dispositivi mobili molto appetibili per l’utilizzo in contesti malevoli, come
ad esempio le botnet [7].
2
http://www.spy-phone-app.com
8
• Denial Of Service. Si tratta di un attacco che mira a generare un disservizio. In generale, è facilmente individuabile e raramente crea un danno irreversibile nel dispositivo.
Principalmente genera sconforto nell’utente attaccato. Gli attacchi spaziano da una diminuzione delle prestazioni, del livello di carica della batteria, fino al blocco del dispositivo
da remoto.
1.2.3
Canali di attacco
I principali attacchi a dispositivi mobile sfruttano sia i canali di comunicazione disponibili, che
le applicazioni malevoli.
Canali di comunicazione
• Servizi di rete mobile tradizionali come GSM, 3G, 4G. Esempi sono gli attacchi di overbilling per il cellulare Siemens S55 [8] o il buffer overflow negli MMS su Windows Mobile
CE. 4.2 [9].
• Wi-Fi : il traffico di una rete Wi-Fi può sempre essere sniffato. Il pericolo è maggiore se
la rete è pubblica oppure se la protezione adottata è debole, come nel caso del protocollo
WEP.
• Bluetooth: gli attacchi Bluetooth sono utilizzati anche per la diffusione di malware tra
devices. Un esempio è Il worm Cabir [10], che visualizza il fastidioso messaggio “Caribe”
all’accensione del dispositivo. Gli attacchi su Bluetooth sono generalmente limitati dalla
necessità di vicinanza tra i dispositivi.
• USB : la connessione USB è comunemente utilizzata per sincronizzare il dispositivo mobile con il PC. Viene anche utilizzata dagli sviluppatori come interfaccia per il debug
delle applicazioni. La sua gestione è importante: l’accesso fisico al dispositivo potrebbe
permettere di ottenere informazioni riservate e di installare applicazioni malevoli.
Malware Il malware è un software progettato per eseguire un payload ostile, intrusivo o
dannoso ad insaputa dell’utente. Attualmente il principale vettore di distribuzione del malware
è Internet. Ad esempio, può essere nascosto nel codice Javascript di una pagina web, in un
applicazione scaricata o sotto forma di allegato di una email.
Storicamente il malware viene classificato in [11] virus (un binario che mira ad infettare altri file,
principalmente eseguibili), worm (caratterizzato da una diffusione ed evoluzione automatica),
trojan (apertura di una backdoor), rootkits (exploit che permette di ottenere i privilegi di
amministratore del sistema), ransomware (limitazione dell’accesso ai file del dispositivo con
richiesta di riscatto). Tuttavia, è bene notare che le minacce moderne difficilmente possono
essere classificate in una sola delle categorie sopra elencate in quanto frequentemente combinano
più varianti.
La somiglianza tra i sistemi operativi mobile con quelli tradizionali ha favorito la migrazione di
software malevoli, inizialmente nati per essere eseguiti su PC, sui nuovi dispositivi. Tuttavia,
la scarsa capacità computazione e le limitazioni imposte dalla batteria rendono le classiche
soluzioni Anti-Virus per desktop non praticabili su smartphone e tablet. Nuove soluzioni,
basate sull’installazione delle sole applicazioni firmate da una Trusted Chain e di framework di
scansione ottimizzati, saranno analizzate in dettaglio nel corso del report.
9
Figura 2: Il messaggio visualizzato da SimpleLocker.
1.2.4
3
Esempio di malware: SimpLocker, un ransomware per Android
Viene di seguito analizzato SimpLocker, un ransomware per Android. Nonostante attualmente
sia diffuso solo per la piattaforma Android, le tecniche impiegate sono generali ed applicabili
anche ad altri sistemi operativi mobile.
Introduzione Verso metà del 2013 Symantec ha rilevato Android Defender (rinominato dalle
aziende di Anti-Virus Android.Fakedefender), il primo ransomware per Android [12]. Si tratta
di un’applicazione che, fingendo di effettuare una scansione e rilevando minacce non esistenti,
blocca il dispositivo fino al pagamento di un riscatto. Il ransomware è un tipo di malware ben
noto che impedisce all’utente l’accesso ai propri file fino al pagamento di un riscatto.
Un anno dopo, a metà del 2014, Symantec ha individuato una nuova variante di ransomware per
Android, conosciuta come SimpLocker, che impedisce l’accesso ai file del dispositivo cifrandoli.
L’applicazione che distribuiva il malware in questione è Sex Xonix, un gioco all’epoca disponibile
su Google Play Store.
SimpleLocker [13] è una versione semplificata di una famiglia di ransomware molto diffusi sulla piattaforma Windows desktop: Dirty Decrypt, CryptoLocker, CryptoWall, CryptoDefense,
TorrentLocker e Cryptographic Locker.
Il malware è disponibile su Android in differenti versioni: 30 sono le varianti conosciute dalle
aziende Anti-Virus, rappresentate tutte con il nome di Android.SimpLocker.
Una volta che l’applicazione viene scaricata ed installata sul dispositivo mobile, il malware
visualizza un messaggio a tutto schermo, riportato in Figura 3, indicando che il telefono è
stato bloccato a causa della presenza e diffusione di contenuti pedopornografici. Per sbloccare
3
Sorgente immagine: http://static.spiceworks.com/shared/post/0002/2091/Fig2 6.png
10
il dispositivo è necessario effettuare un pagamento. Il messaggio può essere chiuso, ma viene
immediatamente visualizzato nuovamente se l’utente tenta di lanciare un’altra applicazione.
Per una maggiore intimidazione, alcuni versioni utilizzano anche la fotocamera del telefono
per catturare la faccia dello sfortunato possessore e minacciano di mandarla ovunque l’autore
del malware lo ritenga necessario. Diverse versioni del malware differiscono nel messaggio
intimidatorio, nell’ammontare dell’estorto e sul metodo di pagamento.
Durante l’installazione l’applicazione richiede i seguenti permessi [14]:
• Accesso ad Internet illimitato.
• Permesso per monitorare lo stato della rete.
• Accesso allo stato del telefono ed il suo ID.
• Permesso di eseguire applicazioni all’avvio del dispositivo.
• Divieto di impostare il telefono in modalità sleep.
• Accesso in lettura SD card.
• Accesso in scrittura su SD card.
Nonostante una lunga lista di permessi richiesti, inusuale per un gioco, non sono inclusi quelli
più allarmanti, come la possibilità di effettuare chiamate e di mandare SMS, inoltre non vi
è la richiesta dei privilegi di root. È comprensibile, quindi, che gli utenti continuassero con
l’installazione dell’applicazione.
I componenti Il malware è composto da cinque componenti:
• Una Main Activity: si attiva quando l’utente tocca l’icona sullo schermo. Lo scopo
principale è quello di bloccare lo schermo, visualizzare un messaggio intimidatorio ed
eseguire il servizio MainService. Tutti i messaggi intimidatori sono memorizzati nel file
APK come stringhe di testo ed lo schermo viene bloccato intercettando se vengono premuti
i tasti di Home, Indietro e Menu.
• Due BroadcastReceiver: ServiceStarter e SDCardServiceStarter. Il primo viene eseguito
quando il sistema viene avviato. Il secondo si avvia quando è disponibile una scheda SD
e si occupa di cifrare i file.
• Due Service: MainService and TorService. Il primo si occupa di fornire le funzionalità di
base del malware. TorService è responsabile della comunicazione con il command server
tramite la rete Tor.
Ricerca e Cifratura dei File Se una scheda di memoria SD è presente nel telefono, il
servizio SDCardServiceStarter si occupa della ricerca e cifratura di tutti i file con le seguenti
estensioni: .3gp, .avi, .bmp, .doc, .docx, .gif, .jpeg, .jpg, .mkv, .mp4, .pdf, .png, .txt. I file
vengono cifrati usando Java Cryptography Extension (JCE) che implementa gli algoritmi di
crittografia di base. Il malware utilizza un algoritmo di cifratura simmetrica AES 256 bit, con
modalità Cipher Block Chaining (CBC). La chiave viene generata a partire da una stringa di
testo, memorizzata nel programma, di cui viene effettuato un hash con algoritmo SHA-256. La
stringa è lunga 12 caratteri e differisce nelle varianti del malware.
11
Figura 3: Prima e dopo la cifratura dei file.4
Essendo AES un algoritmo di cifratura simmetrica, cifratura e decifratura usano la stessa chiave.
Analizzando il codice del malware è possibile ottenere le istruzioni utilizzate per generare la
chiave ed utilizzarle per decifrare i file, senza la necessità che il server di controllo malevole,
Command&Control, invii il comando di sblocco.
Una volta che i file sono stati cifrati, il malware aggiunge l’estensione .enc ai file cifrati, li scrive
sulla scheda SD ed elimina i file originali, come visibile in Figura 3.
In confronto, CryptoLocker [15], la versione desktop del malware, fa uso di una maggiore
complessità nella fase di cifratura: impiega AES per cifrare le informazioni iniziali e RSA, un
algoritmo di cifratura asimmetrico, per cifrare i file del dispositivo. La chiave privata viene
salvata nel Command&Control server, rendendo quasi impossibile il recupero dei file senza
pagamento del riscatto. Per poter confrontare con maggiore dettaglio le tecniche usate nelle
due versioni di malware, di seguito sono elencati i principali passaggi della tecniche di cifratura
usati da CryptoLocker:
• Il malware ottiene delle informazioni sul calcolatore della vittima e le cifra utilizzando
una chiave AES-256 bit generata randomicamente [16].
• La chiave AES viene cifrata utilizzando RSA (1024 o 2048 bit a seconda della versione
del malware) con la chiave pubblica hardcoded del server Command&Control.
• Le informazioni sul computer della vittima (cifrate con AES) e la chiave AES (cifrata con
RSA) vengono inviate al server.
• Il server decifra la chiave AES utilizzando la propria chiave privata ed in seguito decifra
anche le altre informazioni sulla vittima.
• Il server genere una coppia di chiavi asimmetriche RSA (2048 o 4096 bit a seconda delle
versioni), che saranno utilizzate per la cifratura dei file da parte del malware.
4
Sorgente immagine: http://www.symantec.com/connect/blogs/ simplocker-first-confirmed-file-encryptingransomware-android
12
• La chiave pubblica generata viene mandata al client cifrata, utilizzando la chiave AES-256
bit precedentemente inviata.
Connessione con il Command Server La connessione con la rete Tor5 assicura la comunicazione con il Command&Control, il server malevole che viene ospitato nel dominio “.onion”,
rendendo difficile l’identificazione del proprietario. Il nome del server viene specificato direttamente nel programma, differenti versioni utilizzano nomi diversi. Dopo aver stabilito una
connessione, il malware ottiene le informazioni sul telefono (IMEI, numero di telefono, modello,
versione del sistema operativo) e le trasmette al command server per determinare se il pagamento è stato effettuato. In seguito alla conferma del pagamento, un messaggio di risposta dal
server (stop) permette di sbloccare lo schermo e decifrare i file precedentemente cifrati.
Rimozione dell’applicazione malevole In alcuni dispositivi Android, il malware può essere
rimosso velocemente disinstallando l’applicazione Sex Xonix, dopo aver riavviato il dispositivo.
Tuttavia, nella maggior parte dei casi l’applicazione viene caricata cosı̀ velocemente dal sistema
da impedirne la rimozione.
La maggioranza dei dispositivi Android fornisce un’opzione per il boot del sistema operativo
(OS) in Safe Mode. Questo permette di caricare solo le funzionalità di base dell’OS ed impedisce che applicazioni di terze parti vengano eseguite. Android.Simplocker può essere rimosso
eseguendo il sistema operativo con questa opzione. Se dopo l’installazione dell’applicazione
malevole il dispositivo viene immediatamente spento, si può prevenire che molti file vengano
cifrati. In seguito si può procedere alla disinstallazione, come precedentemente spiegato, o ad
un factory reset, riportando il dispositivo alle impostazioni di fabbrica.
Tutti i file cifrati, possono essere decifrati in quanto la chiave utilizzata dall’algoritmo di cifratura simmetrica viene salvata all’interno del malware. Tuttavia non risulta essere un’operazione
semplice per la maggioranza degli utenti che non sono familiari con gli algoritmi di cifratura.
Conclusione Android.Simplocker è il primo ransomware conosciuto per Android che cifra
i file, rendendone impossibile l’accesso. Nonostante questa versione del malware sia molto
semplice, soprattutto se confrontata con Cryptolocker, vi è molto spazio per miglioramenti
futuri.
1.2.5
Proteggersi dagli attacchi
La protezione dalle minacce descritte in 1.2.2 e 1.2.3 può essere implementata su diversi livelli,
di seguito elencati.
• Rete. A livello di rete è possibile monitorare il traffico alla ricerca di anomalie ed implementare alcuni filtri basati sul riconoscimento di patterns malevoli. Nel caso degli SMS,
ad esempio, si potrebbe sospettare un traffico anomalo nella quantità di essi, proveniente
dallo stesso numero telefonico.
• Il sistema operativo. In ambito mobile rappresenta il tipo di protezione più importante.
I sistemi operativi mobile limitano l’adozione di sistemi di sicurezza “detection based”
in favore di soluzioni di tipo “prevention based”. I primi sono dispendiosi nei consumi, i
secondi mirano a prevenire ed, in caso, a limitare i danni inflitti da un software malevole
5
https://www.torproject.org
13
o da altri attacchi precedentemente descritti in 1.2.3. La strategia di prevenzione si
concretizza soprattutto nella realizzazione del “Confinamento delle applicazioni”, uno dei
punti centrali dell’analisi (sezioni 2.5, 3.3, 4.5).
• Store. È il negozio virtuale per la distribuzione di applicazioni. Attualmente ogni sistema
operativo ha il proprio store ufficiale, ma sono presenti anche versioni multipiattaforma,
ad esempio per la distribuzione di applicazioni in tecnologia Web. In ambito mobile
rappresenta il primo filtro per evitare la diffusione di applicazioni malevoli, grazie ad un
processo di revisione che può essere anche completamente automatizzato. Nelle sezioni
2.6, 4.7 verranno trattate in dettaglio le diverse soluzioni adottate per ciascun sistema
operativo analizzato.
• Utente. Parte degli attacchi non sfrutta falle tecnologiche dei dispositivi attaccati, ma
utilizza tecniche di social engineering che portano l’utente ad eseguire operazioni dannose
per la sua privacy o per l’integrità del sistema operativo. Prevenire questi problemi è una
sfida più a livello sociale che tecnologico: sono necessarie campagne di informazione e
di sensibilizzazione degli utenti verso il problema della sicurezza, affinché siano consapevoli delle sempre crescenti situazioni di rischio legate ad un uso non coscienzioso di uno
smartphone. Tuttavia, i sistemi operativi mobile possono offrire un certo livello di protezione attraverso notifiche sui possibili rischi legati ad alcune funzionalità, sull’utilizzo di
impostazioni non sicure o addirittura in alcuni casi, impedendo determinate azioni.
Nel corso del report verranno analizzate nel dettaglio le soluzioni di sicurezza offerte a livello
di sistema operativo, store ed utente. Le operazioni di monitoring della rete sono a carico
dell’operatore e dell’amministratore di rete, esulando pertanto dagli scopi di questo documento.
1.3
Il modello dell’analisi di sicurezza
Nel report saranno analizzati due sistemi operativi emergenti, Ubuntu Touch e Tizen ed il
custom firmware di Android CyanogenMod. Al fine di rendere il documento più omogeneo,
l’analisi è stata condotta secondo un modello comune. Nonostante la diversità dei sistemi
analizzati, sono state selezionate alcune macrocategorie, di seguito dettagliate, in modo da
facilitare l’operazione di confronto tra le soluzioni adottate in ciascun prodotto.
1. Modalità dell’analisi di sicurezza: descrizione del procedimento adottato e delle fonti
impiegate per analizzare il sistema operativo.
2. Introduzione
3. Architettura: descrizione dell’architettura del sistema operativo (il kernel, i componenti
principali, i livelli in cui è suddiviso). Analisi di eventuali componenti di virtualizzazione
e di Framework a supporto delle applicazioni.
4. Il modello di sicurezza del sistema operativo: il modello adottato nella progettazione della
soluzioni di sicurezza. Una visione d’insieme delle tecniche adottate.
5. Tecniche di confinamento delle applicazioni: l’impiego di eventuali tecniche di isolamento delle applicazioni per prevenire e limitare le conseguenze di possibili attacchi. Tali
tecniche consistono nell’isolare ciascuna applicazione, impedendone l’interazione con le
altre. Inoltre, si vuole limitare l’accesso ai componenti del dispositivo e ai dati sensibili
memorizzati.
14
6. Criticità progettuali ed implementative delle applicazioni: valutazione di possibili peculiarità progettuali o implementative che introducono debolezze nella sicurezza delle
applicazioni.
7. Store: analisi del negozio virtuale, nel caso in cui sia disponibile, per la distribuzione di
applicazioni per dispositivi mobili. Il servizio generalmente permette di navigare tra le
applicazioni compatibili con il proprio dispositivo e di scaricarle direttamente sullo smartphone o tablet, sia gratuitamente, che a pagamento. Si vogliono analizzare le possibili
funzioni offerte, tra cui quella di filtrare la pubblicazione di applicazioni sulla base di un
processo di revisione al fine di limitare la diffusione di applicativi malevoli o non adatti,
nei contenuti, per gli utenti.
8. Cifratura: eventuali funzionalità finalizzate a limitare l’esposizione e la perdita di dati sensibili memorizzati all’interno dei terminali, in particolare a seguito della compromissione
fisica di un dispositivo.
9. Componenti di sicurezza aggiuntivi: analisi di eventuali soluzioni di sicurezza addizionali,
specifiche di ciascun sistema operativo.
10. Protezione dell’accesso: analisi dei meccanismi disponibili per la protezione dell’accesso
fisico, il primo livello di protezione applicabile sui dispositivi mobili. È finalizzato ad inibire l’uso non autorizzato in caso di smarrimento o furto ed a proteggere i dati contenuti
al suo interno. In questo contesto rientrano l’impiego della password impostabile dall’utente ed il blocco automatico del dispositivo dopo un certo periodo di inattività. Misure
addizionali riguardano la possibilità di effettuare un reset hardware o la cancellazione dei
dati da remoto.
11. Vulnerabilità note: eventuali falle di sicurezza note pubblicamente, alle quali è stato
assegnato un Identificatore CVE (Common Vulnerabilities and Exposures).
12. Analisi sperimentale: eventuale utilizzo dell’emulatore o di un dispositivo fisico per provare le nozioni acquisite, testare le impostazioni di sicurezza insieme a possibili debolezze
del sistema operativo.
13. Conclusione: note conclusive sull’analisi del sistema operativo. Punti di forza, debolezze, migliorie. Confronto delle soluzioni adottate con quelle offerte nel panorama della
sicurezza mobile.
L’analisi è stata condotta in collaborazione con il Security Lab di “Telecom Italia Information
Technology”. Si ringraziano Roberta D’Amico, Dario Lombardo per il supporto offerto.
In accordo con le loro esigenze, si è deciso di analizzare i tre sistemi operativi con un livello di
dettaglio crescente secondo l’ordine: CyanogenMod, Ubuntu Touch e Tizen. Questa scelta è
dettata anche dal livello di interesse e particolarità dei sistemi in questione. Tizen è indubbiamente il più interessante ed innovativo nelle soluzioni di sicurezza. Ubuntu Touch è un ramo di
Ubuntu, che si vuole aprire al mondo mobile conservando la struttura della versione desktop.
Infine, CyanogenMod è una variante di Android, che rilassa alcuni stretti vincoli di sicurezza a
vantaggio di maggiori funzionalità.
1.4
Conclusioni
La rapida diffusione dei dispositivi mobili, combinata con le maggiori funzionalità offerte, ha
reso il problema della sicurezza di fondamentale importanza, anche in ambito mobile. La
15
disponibilità di una connettività quasi sempre presente, rende i dispositivi mobili soggetti a
diversi tipi di attacco, che possono arrecare un danno economico, materiale, o violare la privacy
dei loro possessori. È evidente che siamo all’inizio di un’era in cui gli attacchi saranno sempre
più sofisticati. Progettare nuove soluzioni di sicurezza ad hoc è una sfida tanto necessaria quanto
difficile: l’adozione delle stesse misure adottate su calcolatori classici è ostacolata dalle limitate
risorse che i dispositivi mobili offrono, in termini di capacità computazionale, ma soprattutto
per l’autonomia di carica. In questo contesto, è fondamentale il ruolo del sistema operativo
mobile, che racchiude quasi interamente le funzioni di sicurezza adottabili.
16
2
Ubuntu Touch
Figura 4: Schermata home di Ubuntu Touch6
2.1
Modalità dell’analisi di sicurezza
Si analizzano ora le caratteristiche di sicurezza di Ubuntu Touch. L’analisi è stata condotta
principalmente sulla base della documentazione ufficiale del sistema operativo presente online.
Oltre a ciò, la natura open source di Ubuntu Touch ha consentito di esplorare le discussioni
pubbliche degli sviluppatori sulle piattaforme online di codesharing, tra cui Launchpad7 . Si
è anche preso diretto contatto con alcuni sviluppatori tra cui Marc Deslauriers, esperto di sicurezza in Canonical8 e uno dei più contribuenti sviluppatori di Ubuntu, il quale ha fornito
consigli su come affrontare l’analisi e chiarimenti. Infine, è stato utilizzato l’emulatore ufficiale
di Ubuntu Touch9 al fine di poter testare la navigazione attraverso le funzionalità del sistema.
In generale, si vuole specificare che l’attuale condizione di sistema operativo neonato ha reso
particolarmente difficile la ricerca di informazioni. La documentazione ufficiale cambia di mese
in mese e contiene a volte informazioni non aggiornate. Alcune delle strategie di sicurezza da
6
Sorgente immagine: https://lwn.net/Articles/540146/.
www.launchpad.net
8
Canonical è la compagnia che sta dietro allo sviluppo di Ubuntu
9
Al momento estremamente limitato.
7
17
adottare sono attualmente ancora in discussione. Lo stato dell’arte, in termini di documentazione e analisi, relativo a Ubuntu Touch è estremamente limitato se non inesistente. Secondo
le nostre ricerche, la presente analisi rappresenta il primo documento che riunisce in modo
ordinato i diversi aspetti di sicurezza di questo sistema operativo. Le suddette ragioni, unite
alla difficoltà di reperire un dispositivo compatibile con Ubuntu Touch (il primo modello di
smartphone con Ubuntu Touch preinstallato è uscito a inizio 2015), hanno portato ad optare
per un’analisi di tipo documentativa e non sperimentale. Poiché, come sarà mostrato nella
sezione 2.3, l’architettura software di tale sistema operativo coincide in gran parte con quella
di Ubuntu Desktop, ed essendo una completa analisi della sicurezza di Ubuntu al di fuori degli
intenti di questo report, si è deciso di analizzare gli aspetti del sistema operativo che hanno
maggior rilevanza ai fini dell’utilizzo in ambiente mobile.
2.2
Introduzione
Ubuntu Touch è una nuova distribuzione di Ubuntu volta al mondo dei dispositivi mobile [17].
Si tratta di un sistema operativo per smartphone e tablet, con un’interfaccia che ricorda molto
Ubuntu Desktop nelle forme e colori. Sebbene la versione desktop e mobile siano al momento
distribuite distintamente, in realtà è bene chiarire che dal punto di vista architetturale non si
tratta di due sistemi distinti [18]: Ubuntu Touch è di fatto Ubuntu 14.04, a cui comunemente
viene aggiunto il suffisso Touch nel caso sia utilizzato in ambiente mobile10 . Si spiega meglio
l’origine di questa scelta e quale innovazione porta con se.
2.2.1
Poca integrazione tra S.O. mobili e fissi
I primi telefoni cellulari erano dotati di capacità computazionale e funzionalità imparagonabili
a quelle dei sistemi fissi. Per questo motivo, il loro campo di utilizzo è rimasto per anni
ben distaccato da quello dei comuni calcolatori. Come presentato nell’introduzione, l’era degli
smartphone sta annientando queste differenze. Ad oggi è possibile fare coi nostri smartphone
quasi tutto ciò che i sistemi desktop permettono. Eppure, nonostante queste differenze in
termini di utilizzo stiano scomparendo, le strutture software che li governano ereditano dal
passato profonde differenze che ostacolano una totale integrazione dei due sistemi. Difficilmente
si può iniziare a scrivere un file su desktop per poi proseguire da smartphone o viceversa.
Nonostante i moderni sistemi Cloud cerchino di ovviare a questo problema (si veda ad esempio
Google Drive), la strada pare ancora lunga, e porta con sé diverse problematiche legate alla
necessità di una connessione internet. Finché dispositivi mobili e fissi erano dedicati a scopi
distinti, tale mancanza di integrazione non rappresentava un problema. Oggi che è possibile
gestire con entrambi le stesse cose, il tema sta acquisendo sempre maggiore rilevanza.
2.2.2
Convergenza
La soluzione a questa poca integrazione proposta da Canonical, il team di sviluppo di Ubuntu,
si chiama convergenza e si basa su un’idea molto innovativa. Dal momento che i moderni
dispositivi mobili possono avere le caratteristiche sufficienti per eseguire un sistema operativo
desktop, si è pensato di lasciarsi alle spalle la storica divisione tra i due mondi, portando su tali
dispositivi lo stesso Ubuntu desktop. Il kernel Linux si adatta bene a diversi tipi di architetture
hardware e, come l’esperienza Android dimostra, può facilmente essere utilizzato anche su questi
10
La terminologia “Ubuntu Touch” pare addirittura non essere ufficialmente riconosciuta dagli sviluppatori,
sebbene sia comunemente utilizzata.
18
device. Tale operazione ha indubbiamente richiesto alcune modifiche, specialmente a livello di
gestione dell’interfaccia (resa in grado di adattarsi a schermi piccoli e touch screen) e dei driver,
che saranno analizzate nella sezione 2.3.
Guardando al futuro, l’idea della convergenza è di unificare il mondo mobile e desktop, ottenendo un dispositivo portatile che, collegato ad una apposita dock station dotata di schermo,
mouse, tastiera e ogni altra interfaccia utile, possa comportarsi esattamente come un computer
fisso e mostrare all’utente un classico sistema operativo desktop. Ad oggi la convergenza non è
stata ancora portata a termine, e Ubuntu Touch (o meglio, l’adattamento di Ubuntu ai dispositivi mobili) è ancora da considerarsi un sistema in via di sviluppo. Al momento è possibile
installarlo solo su alcuni device di casa Google (Nexus 4, Nexus 7, Nexus 10) e, da Febbraio
2015, è in commercio il primo smartphone (Aquaris E4.5) con Ubuntu Touch preinstallato11 .
Fino a Gennaio 2015, sulla pagina web ufficiale del progetto si leggeva che la convergenza sarebbe giunta a completamento con Ubuntu 16.04 LTS. Ora tale pagina è stata rimossa per motivi
a sconosciuti, ma si suppone che il progetto sia ancora in atto.
2.3
Architettura
Come detto precedentemente, l’architettura di Ubuntu Touch coincide quasi interamente con
l’architettura di Ubuntu 14.04 LTS. In Figura 5 se ne ha una rappresentazione schematica.
Si noti come si distinguono 2 macro-blocchi: il kernel Linux e lo strato Ubuntu. Il kernel
inizialmente incluso era la versione 3.13, ma è stato aggiornato alla 3.16 con il rilascio di
Ubuntu 14.04.2 nel Febbraio 2015. Si descrivono ora le componenti di più alto livello.
2.3.1
LXC - Linux Container
Un LXC (Linux Container) è un ambiente per la virtualizzazione a livello di sistema operativo,
che permette l’esecuzione di diversi ambienti Linux isolati tra loro (detti appunto containers)
all’interno di un singolo sistema Linux reale ospitante. Per una trattazione più approfondita si
faccia riferimento all’appendice 6.6.
Si mostrano le ragioni della presenza di un LXC nel caso in questione. Ubuntu Touch sta
indubbiamente entrando nel mercato in ritardo rispetto ai propri concorrenti. Voler sviluppare
un sistema in grado di essere eseguito sul maggior numero di dispositivi possibile richiede di
avere a disposizione per ciascuno di essi i driver di basso livello necessari. Come dichiarato
da Ricardo Salveti all’Embedded Linux Conference 2014, chiedere ai produttori di dispositivi
di rilasciare i driver compatibili con Ubuntu sarebbe stato impossibile. Ubuntu Touch risolve questo problema eseguendo all’interno di un LXC l’Android HAL (Hardware Abstraction
Layer), al fine di utilizzarne i driver e alcuni demoni necessari per la gestione dell’hardware del
dispositivo sottostante.
Come si è detto, il container deve essere ospitato da un altro sistema Linux based, nel nostro
caso Ubuntu. Poiché nel nostro caso l’LXC contiene i driver necessari alla comunicazione con
il dispositivo, il suo avvio avviene durante le primissime fasi del boot. Non appena il sistema
è pronto, l’LXC viene avviato e genera al suo interno il proprio file system. Al termine del suo
caricamento, il processo di boot standard può proseguire ed avviare tutte le funzionalità di più
alto livello. Da questo momento in avanti, le applicazioni possono dialogare con il container, e
11
12
La lista aggiornata dei device supportati è disponibile a https://wiki.ubuntu.com/Touch/Devices.
Sorgente immagine: [18].
19
Figura 5: Architettura Ubuntu Touch
12
.
dunque con l’hardware sottostante, tramite libhybrids 13 , che funge da strato di comunicazione
tra i due [19].
2.3.2
Mir
Mir è il display server. È stato sviluppato per rimpiazzare il vecchio X Window System e
supportare lo sviluppo di Unity 8, la nuova generazione di Unity user interface. In quanto
display server, esso controlla e gestisce a basso livello l’integrazione delle parti della GUI. Ad
esempio, gestisce il mouse e aiuta a combinare i movimenti del mouse con il cursore e gli eventi
di interfaccia che il movimento del cursore causa. La Figura 6 mostra alcune delle funzionalità
di Mir.
2.3.3
Unity 8
Unity8 è la shell grafica utilizzata. Fornisce gli strumenti di interfaccia utili ad utilizzare il
sistema nel modo più user-friendly possibile. Consente operazioni come l’apertura, chiusura,
movimento, ridimensionamento delle finestre, o il cambio di focus tra queste.
Le modifiche avvenute da Unity 7 a Unity 8 sono un passo fondamentale verso la convergenza.
Unity 8 è stata infatti progettata nell’intento di avere un’unica implementazione che potesse
gestire un’interfaccia grafica in grado di adattarsi perfettamente ad una vasta varietà di schermi,
in senso di forme e dimensioni: smartphone, tablet, TV, desktop. Inoltre, sempre pensando ad
un utilizzo nel contesto “converged”, Unity 8 è stata alleggerita rispetto alla versione precedente,
al fine di essere adatta ad un hardware più limitato. Unity 8 è stata sviluppata in gran parte
13
Hybris o libhybris è un livello di compatibilità per computer su cui sono eseguite distribuzioni Linux,
basato sulla libreria GNU C, ed ha lo scopo di rendere possibile utilizzare software scritto per sistemi Linux
Bionic-based Linux, che includono principalmente librerie Android e driver dei dispositivi.
14
Sorgente immagine: http://www.phoronix.com.
20
Figura 6: Le componenti del display server Mir
14
utilizzando il Qt Modeling Language (QML) attraverso il Digia’s Qt framework [20].Si tratta di
un linguaggio basato sull’integrazione di JavaScript e Qt per la progettazione di applicazioni con
interfacce di grande impatto visivo [21]. Qt è una libreria cross-platform, largamente utilizzata
nello sviluppo di applicazioni software con interfaccia grafica [22].
2.3.4
Applicazioni
Tipologie Le applicazioni, cosı̀ come lo stesso Unity, si appoggiano su Mir e Qt. Possono
essere scritte in QML o HTML5. Mentre le applicazioni QML sono necessariamente Local,
ovvero il cui codice risiede in locale, le applicazioni HTML 5 possono essere sia Local che
Hosted, ovvero residenti su website remoti ed eseguite dal browser. Per richiamare l’espressione
utilizzata nella documentazione ufficiale, le applicazioni Web-based (scritte in HTML5) e quelle
native (QML) sono considerate “equal citizens”, ovvero condividono lo stesso modello e possono
(a meno di restrizioni che vedremo in seguito) accedere allo stesso insieme di API del dispositivo.
Le applicazioni HTML 5 sfruttano Apache Cordova. Si tratta di un insieme di API, che
permettono ad una applicazione di accedere tramite JavaScript alle funzionalità native del
dispositivo quali la fotocamera e l’accelerometro. Combinate con un UI framework, nel nostro
caso Qt, permettono di sviluppare un’applicazione utilizzando solo HTML, CSS, e JavaScript.
È previsto anche il supporto per applicazioni scritte in C++, anche se è una pratica meno
frequente [23].
21
Distribuzione Tradizionalmente il software per Ubuntu è distribuito attraverso gli Ubuntu
archives. Tale modello è basato sulla fiducia, barriere all’ingresso e tempi lunghi. Per avere il permesso di pubblicare un pacchetto all’interno di tale archivio, uno sviluppatore deve
dimostrare affidabilità contribuendo molto all’interno della community. Imparare a creare e
modificare tali pacchetti e renderli conformi alla pubblicazione negli Ubuntu archive è complesso, richiede tempo e rappresenta pertanto una grossa difficoltà. Inoltre, tali archivi sono
aggiornati solo con le nuove release di Ubuntu, pertanto i tempi richiesti per la pubblicazione
o l’aggiornamento di un’applicazione sono particolarmente lunghi. Questo processo lungo e
complesso, unito a continui controlli di sicurezza sui pacchetti, garantisce un archivio software
di cui gli utenti si possono fidare, ma non rappresenta un canale tramite cui gli sviluppatori
possono portare agli utenti rapidamente le nuove versioni del proprio software.
L’obiettivo della convergenza e, in generale, la nuova apertura verso il mercato dei dispositivi
mobili, ha reso necessaria l’adozione di un nuovo sistema di distribuzione delle applicazioni. Si
vuole avere un modello di App store, semplice, rapido, dinamico, adatto alla distribuzione di un
elevato numero di applicazioni, in cui anche piccoli sviluppatori (in numero sempre crescente)
possano pubblicare le proprie applicazioni e gli aggiornamenti, in modo che siano subito disponibili agli utenti finali. Inoltre, si vuole aggiungere supporto per la creazione di applicazioni
che saranno eseguite sotto confinamento.
A tal scopo, parallelamente ai tradizionali Ubuntu archives, è stato aggiunto uno store speciale
(al momento non accessibile da browser) dedicato ai cosiddetti Click Packages. Si tratta di
un nuovo formato di packaging utilizzato in Ubuntu Touch e, a partire da Ubuntu 14.10, sulla
versione Desktop. I Click package semplificano notevolmente il lavoro dello sviluppatore. Possono essere creati grazie ad una procedura automatizzata tramite l’Ubuntu SDK, che permette
inoltre la specifica delle impostazioni di confinamento. La procedura di caricamento online
dei Click package richiede pochi minuti attraverso il portale“My Apps” di Ubuntu, e li rende
quasi immediatamente disponibili agli utenti. Dettagli saranno discussi in 2.6. Non esistendo
ancora un nome specifico per lo store online che distribuisce i Click packages, d’ora in avanti lo denoteremo con “App store”, al fine di distinguerlo dai tradizionali repository (Ubuntu
archives).
Applicazioni trusted e untrusted Le applicazioni possono essere distinte in due macro
gruppi: untrusted e trusted dall’OS. Le applicazioni untrusted sono quelle scaricate dall’App
store, per le quali il processo di pubblicazione è più semplice. Tali App sono obbligatoriamente
confinate da un profilo AppArmor (vedremo di cosa si tratta in 2.5). I controlli dello store su
queste App possono essere, sotto opportune condizioni che vedremo in 2.6, automatici. Le App
non fidate possono accedere solo ai propri dati e a quanto espressamente concesso dall’utente,
non possono accedere a funzioni privilegiate del OS, né a particolari API come quelle per la
telefonia. Con l’autorizzazione dell’utente, esse possono accedere ad API sensibili come la
localizzazione o online accounts. Tipicamente non sono supportate da Ubuntu o Canonical.
Le applicazioni fidate sono invece quelle installate come parte integrante del sistema operativo
o distribuite da Ubuntu/Canonical. Di norma queste applicazioni non sono eseguite confinate.
Tali applicazioni possono tipicamente accedere ad ogni risorsa o dato disponibile all’interno
della sessione dell’utente. Hanno accesso limitato ai servizi e dati di sistema secondo il sistema tradizionale di permessi Unix. Sono supportate da Ubuntu e/o Canonical e di norma
costantemente aggiornate.
22
2.4
Modello di sicurezza del sistema operativo
Garantire massima sicurezza è uno dei principi fondamentali dello sviluppo di Ubuntu Touch. Si
riassumono brevemente i punti chiave su cui si basa il modello di sicurezza adottato, indicando
in quali sezioni di questo report sono analizzati.
• Distinzione tra applicazioni Trusted e Untrusted (2.3.4): a seconda della provenienza di
una applicazione, le politiche di confinamento possono essere o meno necessarie.
• Confinamento applicazioni (2.5): è il meccanismo chiave con cui si applica la sicurezza.
Consiste nella definizione di un profilo per ogni applicazione, che ne specifica i permessi.
– Controllo accesso al file system (2.5.3): tramite il profilo sopra detto, è possibile specificare singolarmente a quali percorsi del file system una applicazione può
accedere.
– Protezione accesso a sensori e particolari tipi di dato (2.5.4 e 2.5.5): anche per
i sensori e dati quali la musica, galleria fotografica, calendario ecc... è possibile
definire regole di accesso individuali.
– Protezione condivisione dati tra applicazioni (2.5.6): nonostante il confinamento,
al fine di migliorare l’esperienza utente le applicazioni devono essere in grado di
scambiare dati tra loro, e ciò deve avvenire in modo sicuro.
• Controllo a livello di store (2.6)
– Verifica applicazioni : al fine di garantire un App store funzionale e al contempo
sicuro, è necessario affiancare processi di revisione delle App automatici ad altri
manuali.
– Firma applicazioni: il dispositivo deve poter scaricare applicazioni solo da fonti
attendibili e verificarne l’autenticità.
• Memorizzazione dati critici (2.7): le applicazioni necessitano di un luogo centralizzato
per la gestione di dati critici.
• Cifratura dati utente(2.8): consente di proteggere la segretezza dei dati anche nel caso in
cui protezioni a livello software (di sistema operativo) non fossero efficaci.
• Protezione dell’accesso(2.9): è il sistema base con cui viene impedito lo sblocco del
dispositivo ad un utente non autorizzato.
2.5
Tecniche di confinamento delle applicazioni
2.5.1
La necessità di confinare le applicazioni in Ubuntu
L’introduzione di un App store per la distribuzione dei Click package introduce alcune problematiche di sicurezza: il processo semplificato può facilitare la pubblicazione di malware all’interno
dello store, oppure permettere che applicazioni con falle di sicurezza arrivino direttamente agli
utenti. Ubuntu deve essere pronto ad ospitare in modo sicuro grandi quantità di software non
fidato. Ciò implica la necessità di confinare le applicazioni. Tecniche di confinamento delle
applicazioni sono di uso comune in tablet e smartphones. Da quanto detto in precedenza sulla
convergenza, dovrebbe essere chiaro che, nel nostro caso, le soluzioni adottate per confinare
le applicazioni sono state progettate non in modo specifico per dispositivi mobili, ma per un
23
sistema operativo congiunto, in grado di essere eseguito su smartphones, tablets, smart TV e
desktops. Tali soluzioni, inoltre, necessitano di essere facilmente compatibili con applicazioni
già esistenti. Un’applicazione confinata deve avere il permesso di leggere e scrivere dati solo
da locazioni che sono state precedentemente approvate dall’utente e lo stesso principio vale per
l’uso dei sensori. L’implementazione di una soluzione deve essere il più semplice possibile, e
non deve avere impatto sul tempo di startup di un’applicazione. Anche il sistema di gestione
dei diritti delle applicazioni necessita di essere semplice e comprensibile. La soluzione adottata
in Ubuntu si chiama AppArmor.
2.5.2
Introduzione ad AppArmor
AppArmor è un modulo di sicurezza del kernel Linux che implementa un MAC (Mandatory
access control). Insieme al tradizionale sistema Unix dei permessi utente, permette di limitare
le App a un limitato set di risorse. AppArmor è una tecnologia già matura, utilizzabile per
confinare applicazioni su ogni installazione default Ubuntu a partire dalla versione 7.10 (Ubuntu
Gutsy Gibbon).
Il livello di confinamento che AppArmor adotta su ogni applicazione è definito da profili associati alle applicazioni e memorizzati all’interno del kernel. Se un profilo non viene specificato
per un particolare binario, tale binario non sarà confinato. In tal caso, tuttavia, saranno sempre
valide le restrizioni imposte del tradizionale sistema dei permessi utente Unix. Nel caso di un
programma in esecuzione sotto un determinato profilo AppArmor, qualora questo dovesse tentare l’accesso ad un percorso non autorizzato, AppArmor impedirà tale accesso e il programma
potrebbe andare in crash.
Focalizzandoci maggiormente su AppArmor, il diagramma di Figura 7 rappresenta il suo
funzionamento.
Figura 7: Architettura AppArmor
15
.
Nella parte inferiore della figura si trova il kernel. Il LSM (Linux Security Module, [24]) è
un modulo del kernel Linux che consente di supportare dei MAC policy engine esterni (come
15
Sorgente immagine: http://ftpmirror.your.org/pub/wikimedia/images/wikipedia/commons/b/b1/AppArmor.pdf.
24
AppArmor) e renderli parte integrante del kernel. Tramite l’LSM, AppArmor ha la possibilità
di operare a livello kernel pur non facendone propriamente parte. Ciò consente di conservare
all’interno di AppArmor le policy di sicurezza per ogni applicazione, evitando di dover applicare
patch al kernel tutte le volte che si ha il bisogno di modificarle. Fondamentalmente, LSM chiede
ad AppArmor se le operazioni che un’applicazione vuole eseguire possono essere concesse. Nella
parte superiore dell’immagine si trova l’AppArmor management software (nello schema semplicemente AppArmor), che rappresenta l’insieme di tool per modificare manualmente le policy.
In arancione sono rappresentate le applicazioni, ognuna delle quali potrà avere un’AppArmor
policy corrispondente che ne descrive i permessi.
Secondo i progettisti di AppArmor, portare la sicurezza a livello kernel, come permesso dall’interfaccia LSM, è di importanza fondamentale ai fini di garantire la sicurezza. Come Crispin
Cowan, direttore del Software Engineering Security Architect, ha detto, la sicurezza fatta a
livello di libreria è solo apparente, sembra che le applicazioni non possano fare quel che gli è
vietato, ma l’attaccante che riesce a infettare l’applicazione può bypassare la libreria e arrivare
al kernel. Questo, invece, non è il caso della sicurezza a livello di kernel [25].
È risaputo che, di norma, una lista di permessi può essere espressa secondo un modello black
list (in cui tutto è concesso a parte quanto espressamente vietato) oppure white list (in cui tutto
è vietato tranne quanto espressamente concesso). Il secondo è indubbiamente un modello più
sicuro, ma più difficile da mantenere perché per funzionare bene richiede che nessun permesso
di quelli necessari sia omesso. Quello di AppArmor è una sorta di modello ibrido: a livello di
applicazione usa una white list, perché specifica i percorsi a cui essa può accedere, quando tutti
gli altri sono vietati. A livello di sistema è invece una black list, perché solo le applicazioni con
una policy definita saranno ristrette. Quando un eseguibile viene lanciato, il kernel esamina il
suo percorso e cerca se esiste una policy definita da applicare per tale applicazione. Se non la
trova, l’applicazione sarà avviata non confinata.
Tramite la aa-exec utility è possibile eseguire un certo programma sotto un determinato profilo
AppArmor, specificato a parte, e tramite l’API aa change profile si può cambiare profilo a
un programma durante l’esecuzione. AppArmor si occupa inoltre di far ereditare le policy del
parente ai nuovi eseguibili lanciati a runtime.
2.5.3
AppArmor profile
Si tratta di un file di testo contenente le regole che descrivono le risorse a cui un’applicazione
può accedere. In particolare può specificare:
• Controllo di accesso sui singoli percorsi;
• Controllo di accesso a funzionalità di sistema [26];
• Controllo di accesso a D-Bus;
Si mostra di seguito un esempio di profilo AppArmor:
#i n c l u d e <a b s t r a c t i o n s / base>
c a p a b i l i t y sys time ,
capability sys chroot ,
dbus ( send )
25
bus=s e s s i o n
path=/o r g / f r e e d e s k t o p /DBus
i n t e r f a c e=o r g . f r e e d e s k t o p . DBus
member=H e l l o
p e e r =(name=o rg . f r e e d e s k t o p . DBus ) ,
deny s i g n a l ( send ) s e t =( i n t ) ,
/ e t c / ntp . c o n f
/ e t c / ntpkeys
/tmp/ ntp ∗
...
r,
x,
rw ,
Se ne analizza brevemente il contenuto.
• La direttiva include semplifica l’inclusione di alcune regole.
• Tramite la keyword capability si specifica a quali servizi di sistema è concesso l’accesso.
Una lista delle capabilitie supportate è disponibile in [26].
• Successivamente si trova la dichiarazione di un permesso di tipo D-Bus. D-Bus è il
meccanismo utilizzato in Ubuntu e molti altri sistemi POSIX per l’IPC (Inter Process
Communication).
• La keyword signal è utilizzata a partire da Ubuntu 14.04 LTS per specificare quali segnali
un’applicazione può inviare e/o ricevere. Nel caso visto sopra, si vieta all’applicazione di
inviare segnali di interruzione ad altri processi.
• Infine si ha la dichiarazione dei percorsi consentiti con i relativi permessi di lettura/scrittura/esecuzione. Si noti come quest’ultima possa essere semplificata attraverso l’uso
di regular expressions.
Visto questo formato del profilo AppArmor di un’applicazione, appare complicata la gestione
di permessi quali “accesso alla fotocamera”. Per questo motivo sono utilizzati i Policy Groups.
Confronto con SeLinux SeLinux è un modulo per il kernel Linux che fornisce, come AppArmor, la possibilità di implementare Mandatory Access Control. Questo, anziché utilizzare
percorsi, assegna i programmi a certi domini e certi tipi (etichette) ai file. Le policy specificano quali domini possono accedere a quali etichette. Il problema di SeLinux è che i file con
la stessa etichetta fanno parte della stessa classe di equivalenza: se in futuro si introduce un
nuovo programma che vuole considerare distintamente due file etichettati in modo uguale, bisognerà introdurre nuove etichette e apportare modifiche anche alle configurazioni dei vecchi
programmi. Per dettagli su SE-Linux vedere [27].
2.5.4
Policy Groups
Specificare il profilo AppArmor direttamente all’interno del package dell’applicazione rappresenterebbe una grande complicazione nella mani dello sviluppatore, non in linea con la filosofia
volta alla semplificazione discussa precedentemente. Inoltre, permettere agli sviluppatori di
scrivere manualmente il profilo AppArmor per le applicazioni destinate allo store online, renderebbe difficile la revisione automatica delle applicazioni. Tale processo si basa, infatti, sui
26
permessi concessi all’App. I Policy Groups rappresentano la soluzione a questo problema. Il
profilo AppArmor non viene scritto manualmente dagli sviluppatori, bensı̀ generato automaticamente al momento dell’installazione sulla base di direttive di più alto livello (Policy Groups)
definite all’interno del Click package. Si vuole vedere nel dettaglio come funziona.
All’interno di un file manifest, contenuto nel Click package di un’applicazione, sono specificati
i Policy Groups che tale applicazione richiede. Esempi di Policy Groups sono:
• camera: accesso alla fotocamera;
• content exchange.: permesso di condividere contenuto;
• location: accesso ai servizi di localizzazione;
• contacts: accesso alla lista dei contatti;
• gallery: accesso alla galleria immagini;
• networking: permesso di comunicare tramite le interfacce di rete.
Insieme a specifici Policy Groups è possibile indicare un template da cui partire, che rappresenta
un insieme di regole AppArmor predefinito, adatto ad un particolare tipo di applicazione. Al
momento i Policy Templates supportati sono:
• ubuntu-sdk: template di default, se nessun altro specificato.
• ubuntu-webapp: un template specializzato per l’utilizzo con la piattaforma Ubuntu
Webapps.
• ubuntu-scope-network: template specializzato per gli scopes16 che richiedono accesso
a internet. Di norma agli Scopes non è concesso utilizzare la stessa gamma di Policy
Groups concessa agli altri tipi di applicazione.
• unconfined: fornisce permessi massimi all’applicazione. Questo template è riservato
ad applicazioni che sono specificamente fidate e non può essere utilizzato da normali
sviluppatori.
Di seguito si mostra un esempio di file manifest.json. Il file contiene un oggetto “Hooks” che
trasporta le informazioni di nostro interesse. Potrebbe apparire ad esempio in questo modo:
{
[...]
hooks :
{
myApp :
{
apparmor : myApp . j s o n ,
co nte nt −hub : myAppCH. j s o n }
[...]
}
}
[...]
}
16
In Ubuntu Touch, uno scope è una sorta di widget posizionabile nella schermata di home.
27
Ciò vuol dire che il file myApp.json contiene sia le informazioni relative ad AppArmor, sia
quelle specifiche per il content-hub (vedremo in seguito di cosa si tratta). Il file myApp.json
potrebbe avere un contenuto come il seguente, in cui comunica che si vuole poter accedere alla
videocamera, al GPS e al microfono.
{
policy groups : [
camera ,
microphone ,
location
],
policy version : 1
}
Al momento dell’installazione, un tool automatico di nome aa-easyprof crea il profilo AppArmor corrispondente al template e ai Policy Groups specificati. Come mostrato in Figura
8, ognuno dei possibili Policy Groups rappresenta diverse entry nel formato AppArmor. È
importante notare che, come sarà illustrato in 2.5.5, specificare ad esempio camera nei policy
groups, non significa che, una volta installata, l’applicazione avrà il permesso di accedere alla
fotocamera: servirà un ulteriore consenso dell’utente, fornito attraverso i cosiddetti Truster
Helpers.
Figura 8: Scelta Policy Groups
17
La lista di Policy Groups svolge, inoltre, il ruolo di semplificare il processo di revisione di un’applicazione. Lo store legge automaticamente il contenuto del file manifest e ne estrae i permessi
richiesti. Qualora fossero richiesti Policy Groups non considerati pericolosi, l’applicazione sarebbe immediatamente accettata. In caso contrario, potrebbe subire un processo più lungo di
revisione manuale.
2.5.5
Gestione autorizzazioni: Trusted Helpers
Si è visto come il profilo AppArmor di un’applicazione specifichi con quali servizi tale applicazione possa comunicare e a quali percorsi possa accedere. Il permesso di comunicazione con
17
Sorgente immagine: https://developer.ubuntu.com/en/publish/security-policy-groups/.
28
servizi che gestiscono dei dati o sensori, non è però sufficiente a consentire all’App l’accesso a
questi ultimi. Serve esplicita autorizzazione dell’utente, si mostra ora come.
Nel modello di sicurezza adottato, gli utenti prendono decisioni riguardo la concessione di
operazioni sensibili nell’esatto momento in cui esse sono richieste. Ciò è ottenuto attraverso l’uso
di componenti che prendono il nome di Trusted Helpers. In generale, gli helpers sono processi
che gestiscono l’accesso di una applicazione a dei servizi esterni: ad esempio, esiste l’helper della
fotocamera, con cui un’applicazione deve comunicare se vuole scattare foto. Esistono anche
helper per il calendario, i contatti ecc... La comunicazione con tali helper avviene attreverso
D-Bus, dunque, poichè le comunicazioni tramite D-Bus sono controllate da AppArmor, il profilo
di sicurezza di un’applicazione potrebbe vietare la comunicazione con certi helpers. Qualora
invece il profilo AppArmor concedesse tale comunicazione, l’helper potrebbe gestire l’accesso
alla risorsa di sua competenza visualizzando un messaggio di conferma all’utente. In tal caso
prende il nome di Trusted Helper. I Trusted Helpers rappresentano dunque il punto in cui
l’utente può prendere la decisione di concedere o negare un certo privilegio, indipendentemente
da quanto scritto sul profilo AppArmor. Infatti, il contenuto del profilo AppArmor non è
visualizzato all’utente, e dipende solo da quanto dichiarato nel file di manifest dell’applicazione,
compilato dallo sviluppatore. Questo modello fa si che i privilegi richiesti all’interno del file
di manifest rappresentino solo ciò di cui l’applicazione potrebbe aver bisogno, ma accettare di
installare un’applicazione che richiede l’accesso alla fotocamera non vuol dire, come nel modello
Android, già consentire tale accesso, ma significa concedere alla App di richiedere al Trusted
Helper della fotocamera di utilizzare tale servizio.
I Trusted Helpers possono anche svolgere funzioni più complesse che gestire un accesso “booleano” di una App. Un esempio è quello degli Online Accounts: la AppArmor policy “online
accounts” specifica se una App può comunicare o meno con l’helper degli Online Accounts,
ma tale helper dovrà gestire al suo interno la scelta dell’account specifico a cui fornire accesso. Ciò sarà fatto attraverso opportuni messaggi di richiesta (ad esempio “Vuoi consentire
all’applicazione X di accedere all’account Y?”). Online Accounts può memorizzare in cache la
risposta. Come si può intuire, questo sistema mischia le policy di AppArmor con quelle dei
Trusted Helpers. Infatti, Online Accounts agli occhi dell’utente è come se stesse modificando
le policy di sicurezza quando salva la scelta di un utente, sebbene il profilo AppArmor resti
sempre invariato. In questo modo è possibile dalle impostazioni modificare in un secondo momento i permessi concessi ad una applicazione. Ad esempio sarà possibile revocare l’accesso
ai contatti. Secondo la documentazione, questo modello su due livelli (AppArmor e Trusted
Helpers) potrebbe essere rivisto in futuro a favore di uno unico, in modo che sia più ordinato
e gestibile [28].
2.5.6
Condivisione contenuti: Content Hub
Nonostante le applicazioni siano confinate, esse spesso hanno bisogno di scambiare dati con
altre applicazioni. Si è visto come i Trusted Helpers possano mediare l’accesso a servizi quali
fotocamera e GPS, ma come funziona il trasferimento sicuro di file come immagini e musica
tra applicazioni? Come può una App essere esportatrice o importatrice di un certo tipo di file?
Il meccanismo sviluppato per risolvere questi problemi si chiama Content Hub. Il suo scopo è
quello di fornire una API e un servizio runtime che dia alle App la possibilità di condividere
e importare contenuto da altre applicazioni. Al momento, lo sviluppo del Content Hub non è
ancora terminato, tuttavia se ne discutono qui le principali caratteristiche.
Content Hub si basa su alcuni principi chiave:
29
• Il contenuto è proprietario: ogni pezzo di contenuto è posseduto da una e una sola
applicazione. Non esiste un’applicazione che possiede, ad esempio, tutte le immagini.
• Ciascun contenuto ha una App di default: per esempio, l’applicazione predefinita per le
immagini è la Gallery.
• Le applicazioni possono registrarsi come sorgente per un certo tipo di contenuto: questo
permette al sistema di mostrare una lista di App sorgenti da cui lo user possa scegliere
nel caso voglia importare un file. Oppure, un’App che sta importando può nominare una
applicazione sorgente.
• Le applicazioni possono registrarsi come destinazione per un certo tipo di contenuto: il
sistema può allora mostrare le applicazioni che possono ricevere questo tipo di contenuto.
Ad esempio, l’utente potrebbe voler salvare un’immagine dal web browser, il sistema gli
presenta una lista di applicazioni tra cui può scegliere dove salvarla.
• Content transfer object: è l’oggetto che rappresenta un trasferimento. Ha una applicazione sorgente, una destinazione, del contenuto e uno stato. Una applicazione sorgente
carica il contenuto che vuole esportare all’interno di questo oggetto; quando ha terminato,
imposta il transfer state a charged, e il trasferimento può cominciare.
• Le applicazioni sorgenti di norma forniscono un selector GUI che permette all’user di
selezionare il contenuto che desidera, per poi far tornare il focus all’applicazione che sta
importando.
Sulla base di questi concetti, viene descritto il funzionamento di Content Hub tramite un
esempio. Si immagini che una App voglia importare delle foto da una sorgente di foto di
default.
1. L’applicazione comunica al content hub che essa vuole usare la sorgente di default per le
immagini (Gallery ad esempio).
2. Il Content Hub passa alla App che sta importando un transfer object che la connette alla
App sorgente.
3. Il Content Hub lancia il selector GUI della App sorgente per la selezione delle immagini
da parte dell’utente. A quel punto il transfer object viene caricato con le immagini
selezionate e segnato come pronto. Infine la galleria viene chiusa.
4. La nostra applicazione in ricezione vede che il transfer object è pronto (dal suo stato) ed
è pronta ad importare l’immagine.
5. La nostra applicazione può utilizzare l’immagine e salvarla in modo permanente utilizzando una apposita API (“contentStore”).
Come si è visto, il Content Hub, tramite il trasfer object, fa da intermezzo tra le due applicazioni. L’utilizzo di un’interfaccia appartenente all’applicazione sorgente per la selezione delle
immagini, garantisce che l’applicazione di destinazione non acceda in alcun modo al contenuto non desiderato dall’utente. Questo sistema consente inoltre di non dover fornire l’accesso
completo a tutte le immagini, ma solo a quelle desiderate. Figura 9 mostra un confronto tra i
sistemi di condivisione contenuti utilizzati su diverse piattaforme.
18
Sorgente immagini: https://design.ubuntu.com/apps/patterns/content-hub.
30
(a)
(b)
(c)
Figura 9: Confronto tra il modello di condivisione dei contenuti: (a) Ubuntu Touch, (b)
Windows, (c) iOS 18
1. Ubuntu Touch: ciascuna App è confinata e può scambiare contenuto con le altre App
tramite Content Hub.
2. Windows: le applicazioni non sono confinate e possono accedere ognuna al contenuto
dell’altra.
3. iOS : simile a Content Hub, ma invece di un singolo Hub esistono dei “Content Pools”
che trattano contenuti specifici. Ad esempio il Music Content Pool. Le applicazioni
condividono contenuti tramite questi “pools”.
Registrazione di una App come sorgente o destinazione Come detto, le App che esportano contenuto (App sorgenti) hanno bisogno di registrarsi come sorgenti per quel determinato
tipo di contenuto. Allo stesso modo, le App si possono registrare per poter essere destinatarie
di un certo tipo di contenuto. Questa registrazione consiste nel renderlo noto al Content Hub.
La registrazione avviene attraverso le informazioni inserite nel file di manifest. Rifacendosi
all’esempio della sezione 2.5.4, il file myAppCG.json potrebbe contenere il seguente contenuto
per segnalarsi come sorgente di immagini [29] [30].
{
{
source : [
pictures ]
}
}
2.6
Store
Si tratta ora il percorso di un’applicazione dallo sviluppatore all’utente finale. Nell’interesse di analizzare particolarmente la sicurezza di Ubuntu Touch, ci si concentra sul caso dei
ClickPackages, scaricabili dall’App store, e considerati untrusted secondo il modello adottato.
2.6.1
Creazione e firma digitale delle applicazioni
Lo sviluppo di un modello più veloce di App store, di cui si è parlato nella sezione 2.3.4, ha
portato con se anche l’adozione di un nuovo sistema di impacchettamento delle applicazioni,
31
denominato ClickPackages. I ClickPackages sono semplici pacchetti di installazione, la cui
procedura di creazione è notevolmente semplificata attraverso l’uso dell’Ubuntu SDK. Tramite
l’Ubuntu SDK è possibile, al momento della creazione del pacchetto, specificare i Policy Groups,
in modo tale da automatizzare la creazione del file manifest associato. Dettagli del file manifest
restano comunque modificabili manualmente. Dopo aver creato il pacchetto, lo sviluppatore
può firmarne il contenuto utilizzando una propria chiave privata. Tale chiave, insieme alla
sua corrispondente chiave pubblica, può essere generata tramite l’Ubuntu SDK. Per la firma si
utilizza il tool debsign tra le cui opzioni è possibile speicifcare che la firma è di tipo maint,
ovvero si tratta della firma di chi si occupa del mantenimento del pacchetto. Nel caso in cui
lo sviluppatore desideri firmare il pacchetto con la propria chiave privata, è necessario che egli
pubblichi sul portale Online di Ubuntu, nella sezione relativa al proprio profilo (accessibile
tramite apposite credenziali), la corrispondente chiave pubblica. Dunque, possiamo dire che,
di fatto, la firma garantisce che lo sviluppatore del pacchetto in questione sia il possessore di
tali credenziali, ma non da alcuna garanzia sulla persona fisica che sta dietro ad esse.
2.6.2
Upload, controllo e firma digitale dello store
Una volta preparato il Click package, eventualmente firmato, si procede al caricamento tramite
un’apposita pagina web (https://myapps.developer.ubuntu.com) sul portale MyApps, dove allo
sviluppatore è richiesto di autenticarsi tramite username e password. A caricamento completato,
se il pacchetto era firmato, MyApps verifica che la firma dello sviluppatore sia valida.
Successivamente lo store esegue i controlli di sicurezza. Se i Policy Groups utilizzati non sono
considerati pericolosi, la App è automaticamente approvata. Altrimenti può essere soggetta a
un controllo manuale, in cui alcuni tecnici possono ispezionare il codice sorgente.
Ad applicazione approvata, lo store firma automaticamente a sua volta il pacchetto utilizzando
sempre debsign e la propria chiave privata. Questa viene specificato che la firma è di tipo
origin, ovvero dell’entità che si occupa della distribuzione del pacchetto agli utenti. Infine, lo
store genera e memorizza lo SHA-512 del pacchetto finale firmato [31].
2.6.3
Download e verifica della firma digitale
Nel momento in cui un device cerca informazioni su un pacchetto, riceve dallo store dei metadati
che contengono i seguenti campi: un download url che contiene l’url da cui scaricare il click
package, e il download sha512 che contiene lo SHA-512 del click package, precalcolato dallo
store. Quest’ultimo sarà utilizzato dal servizio di download eseguito sul dispositivo per validare
l’integrità del pacchetto ricevuto. Si mostra il procedimento nel dettaglio:
• ClickScope19 , sul device, richiede allo store online le info di url e hash del pacchetto che
vuole scaricare.
• ClickScope chiede al DownloadManager di iniziare il download.
• Il download manager scarica il pacchetto e convalida lo SHA-512 per essere sicuro che
non sia corrotto.
• Il download manager chiede all’install helper di iniziare l’installazione, passandogli il
file appena scaricato. La comunicazione con l’install helper avviene tramite D-Bus ed è
mediata da AppArmor.
19
ClickScope è il modulo dedicato alla ricerca di nuovi pacchetti installabili
32
• L’install helper chiede a Package Kit di installare il Click package.
• Package kit verifica la firma dello store e porta a termine l’installazione.
Come detto nella sezione 2.5.4, nel corso dell’installazione sarà creato e memorizzato il profilo
AppArmor corrispondente ai Policy Groups dichiarati.
Al momento si sta valutando se (e come) concedere in futuro di poter accettare pacchetti firmati
solo dallo sviluppatore e non dallo store [31].
2.7
Memorizzazione dati critici
2.7.1
GNOME Keyring e AppArmor
Oggi si sta ancora valutando come integrare GNOME Keyring, discusso in appendice, con il
sistema di confinamento di AppArmor. Al momento per default è vietato l’accesso diretto a
questo servizio da parte delle App confinate. Possono invece accedervi altri servizi come Online
Accounts. Si pensa che, in futuro, se un’App necessiterà dell’uso di Keyring, tale accesso sarà
mediato da Apparmor: quando un’applicazione vorrà recuperare delle credenziali, se il profilo
AppArmor glielo consentirà, sarà concesso l’accesso solo alla credenziali salvate da quella stessa
applicazione. Si sta valutando anche se estendere l’integrazione di AppArmor al fine di rendere
possibile l’accesso a credenziali che appartengono ad altre applicazioni, permettendolo o direttamente nell’AppArmor profile oppure visualizzando all’utente una richiesta di autorizzazione
[32].
2.7.2
Credenziali web: Ubuntu online accounts
È un luogo centralizzato per memorizzare le credenziali degli account web. Ogni applicazione
avviata dall’utente può accedere al database file degli account. Ubuntu Online Accounts è
accessibile tramite D-Bus. L’accesso alle credenziali che esso contiene è protetto, come per
altri servizi, su due livelli distinti (vedi sezione 2.5.5). Un booleano specificato in AppArmor
specifica se tale applicazione può in generale accedere al servizio Ubuntu Online Accounts.
Successivamente è compito di quest’ultimo di gestire i permessi sul singolo account (ovvero a
quali degli account memorizzati una certa applicazione può accedere), e, in caso di necessità, è
visualizzato a runtime un avviso che chiede se concedere o meno l’autorizzazione [32].
2.8
Cifratura dati utente
2.8.1
Introduzione a eCryptfs
La cifratura dei dati utente rappresenta una protezione principalmente contro gli attacchi offline.
In particolare è in grado di proteggere la segretezza dei dati nel caso in cui il dispositivo mobile
fosse rubato o in generale si riuscisse a scavalcare le protezioni a livello del sistema operativo. Si
noti che, al contrario, le tecniche di isolamento delle applicazioni discusse precedentemente sono
protezioni a livello software, il quale progettato in modo da vietare l’accesso non autorizzato a
dati che però sono fisicamente memorizzati in chiaro. Cifrando i dati si ha invece protezione
a livello fisico, nel senso che abbiamo la “certezza” che se anche un utente malevolo riuscisse
ad avere accesso fisico all’hard disk (ad esempio connettendolo ad un altro computer o più
semplicemente eseguendo il boot con un altro sistema operativo) non sarebbe in grado di
decifrarne il contenuto, senza conoscere il segreto che lo protegge.
33
Al momento, le opzioni di cifratura dei dati utente possibili su Ubuntu Desktop, non sono
replicate nella versione Touch. Ubuntu sta pianificando di portare queste soluzioni anche sui
dispositivi mobili. Gli sviluppatori hanno confermato che questa funzionalità sarà implementata
utilizzando il file system crittografico eCryptf, nello stesso modo in cui esso è utilizzato in
Ubuntu Desktop.
Si tratta di un file system crittografico “stacked”. Il termine stacked indica che esso si dispone
al di sopra del file system già presente, indipendentemente da quale esso sia, e ne protegge
i file cifrandone il contenuto e inserendo metadati crittografici nei rispettivi header. Questa
soluzione a livello di file system consente ai file protetti di essere maneggiati normalmente,
copiati tra diversi host e decriptati solo in un secondo momento. Lo svantaggio risiede nel fatto
che, sebbene il contenuto dei file sia cifrato, la struttura del file system sia sempre in chiaro. La
soluzione complementare alla crittografia a livello di file system (file system level encryption) è la
full disk encryption, non disponibile in Ubuntu Touch, che cifra l’intero file system ma, oltre ad
essere computazionalmente più dispendiosa, non consente i vantaggi suddetti. Vantaggio della
full disk encryption è che, cifrando l’intero disco, protegge anche lo spazio di swap20 , lasciato
invece sempre in chiaro da eCryptfs. Questo avviene perché, per questioni di ottimizzazione,
lo spazio di swap viene gestito con un particolare file system dedicato gestito direttamente dal
kernel. Il rischio maggiore si corre nel caso in cui il dispositivo fosse lasciato in ibernazione:
in tale circostanza, il contenuto della RAM, prima che il dispositivo si spenga, è copiato nello
spazio di swap e eCryptfs non ha modo di proteggerlo.
2.8.2
Funzionamento di eCryptfs
Figura 10: Schema di utilizzo delle chiavi in eCryptfs
20
21
.
Lo spazio di swap è una porzione di hard disk che funge da RAM virtuale, ed è utilizzato quando la memoria
non è sufficiente a soddisfare le richieste dei processi in esecuzione.
21
Sorgente immagine: [33].
34
Si illustra ora il funzionamento di eCryptfs, con riferimento alla Figura 10. Il sistema di gestione
delle chiavi utilizzato in eCryptfs si ispira alle specifiche OpenPGP (RFC 2440). Ciò include
la procedura di utilizzare una gerarchia di chiavi nell’eseguire operazioni crittografiche.
Il contenuto di ogni file da proteggere è diviso in blocchi da 128 bit e cifrato con AES-128CBC tramite le Crypto API del kernel Linux. La chiave di cifratura prende il nome di File
Encryption Key (FEC), ed è generata in modo casuale al momento della creazione del file. La
FEC viene poi a sua volta cifrata con un’altra chiave, detta File Encryption Key Encryption
Key (FEKEK), per ottenere la Encrypted File Encryption Key (EFEK). La EFEK viene infine
memorizzata all’interno dell’header del file in questione. Resta da capire l’origine della FEKEK.
Tale chiave nei dispositivi desktop è ottenuta direttamente dalla password di login. Nel caso di
device mobile, possiamo pensare al login come allo sblocco del device22 . Al momento del login,
alla password utilizzata viene aggiunto del sale e applicata ricorsivamente una funzione di hash
(generalmente HMAC-SHA-512), il cui risultato è la FEKEK. A questo punto la FEKEK viene
memorizzata nel kernel keyring fino al logout dell’utente23 . Ciò permette di evitare di eseguire
più volte nel corso della stessa sessione l’algoritmo di hashing suddetto, il quale è volutamente
“lento” (1000 o più iterazioni) al fine di contrastare attacchi di tipo brute-force.
Si mostra ora come avviene l’accesso ad un file protetto da eCryptfs. Le applicazioni, eseguite
nello userspace, fanno richieste di accesso a files tramite system calls al Virtual File System
(VFS) del kernel. Sia eCryptfs, sia il file system a esso sottostante (ad esempio ext3, JFS,
NFS ecc...) sono registrati nel VFS. Nel momento in cui è richiesto l’accesso a un file cifrato,
eCryptfs recupera nel keyring del kernel la FEKEK, memorizzatavi al login. Questa chiave
viene utilizzata per decifrare la EFEK letta dall’header del file richiesto. La FEK cosı̀ ottenuta
viene memorizzata nei metadati di eCryptfs relativi al file in questione e utilizzata per decifrare
il contenuto del file [34][35][33].
2.9
Protezione dell’accesso
Come ogni sistema operativo mobile, insieme alle protezioni di basso livello viste precedentemente, Ubuntu Touch offre la possibilità di proteggersi dal furto di dati bloccando il dispositivo con
una password alfanumerica da 5 caratteri. La password non viene memorizzata in chiaro bensı̀
viene aggiunto del “sale” e il suo hash con MD5 è salvato in /etc/shadow. Per maggior sicurezza, sono eseguite 5000 iterazioni della funzione di hash. L’aggiunta di sale è utile ad esempio per
difendersi contro attacchi di tipo dizionario. Il formato di salvataggio prevede una stringa con
3 campi separati dal carattere dollaro, ad esempio $1$jQdk4iTA$lanDFksSowpaElsSD, dove i
campi sono:
• algoritmo di hash utilizzato (1 significa MD5)
• sale aggiunto alla password
• hash di password + sale
Secondo le nostre fonti, e a quanto risulta dal test sull’emulatore, non sembrano esistere altri
sistemi di protezione.
22
Al momento non si hanno dettagli a come questo sarà gestito. È anche possibile che sarà considerato come
login solo il primo accesso dopo l’avvio del dispositivo.
23
Anche qui, potrà essere lo sblocco o lo spegnimento del dispositivo.
35
2.10
Altri elementi di sicurezza
2.10.1
GSettings/dconf
GSettings è uno strumento per memorizzare le impostazioni di configurazione delle applicazioni. Sfrutta dconf come back end plugin, con cui i processi comunicano tramite D-Bus per
leggere e scrivere le impostazioni dal e sul database. Le applicazioni non confinate possono
leggere e modificare impostazioni per le altre applicazioni. Ciò potrebbe voler dire, ad esempio,
aggiungere plugin arbitrari che siano eseguiti al caricamento di un’altra applicazione. Anche
solo avere l’accesso in lettura alle impostazioni delle altre applicazioni può esporre informazioni
sensibili e causare problemi di privacy.
Dalla versione 13.10 le App confinate non hanno accesso a GSettings. Nonostante si potrebbe
utilizzare una protezione di tipo booleano per l’accesso, specificata tramite AppArmor, secondo
gli sviluppatori non si avrebbe abbastanza sicurezza. In futuro, si legge nella documentazione,
si potrà permettere alle applicazioni confinate di salvare le loro informazioni in GSettings, ma
ciò richiederà una modifica di dconf, in modo tale che sia in grado di tener conto di quali
impostazioni un’applicazione può andare a leggere. La mediazione di AppArmor sul D-Bus
medierà la comunicazione tra le applicazioni confinate e il demone dconf.
2.10.2
Display manager
Come descritto in 2.3.2, Ubuntu usa il server grafico Mir. Si elencano alcuni dei problemi di
sicurezza che Mir, con l’aiuto delle policy di AppArmor, ha risolto rispetto al precedente X
Server.
• Keyboard and mouse sniffing: alle applicazioni eseguite sullo stesso X server era
concesso eseguire operazioni di sniffing dei tasti premuti e eventi del mouse. Questo
poteva permettere ad una applicazione di catturare i dati inseriti in altre applicazioni.
• Screenshot: in X ogni applicazione poteva scattare screenshot anche quando in background. Ciò permetterebbe alle applicazioni di catturare dati sensibili mostrati in altre
applicazioni. La progettazione di Mir previene queste azioni (una normale applicazione
può solo fare lo screenshot del proprio contenuto).
• XSettings: il protocollo XSettings fornisce un meccanismo per far condividere a diverse
applicazioni le stesse impostazioni di interfaccia quali il timeout per il doppio click e i colori
di interfaccia. Il Settings Manager usato in X mantiene una finestra unmapped (unica
per tutti i processi) dove sono memorizzate tutte le impostazioni. Esistono toolkits, come
GTK, che permettono il caricamento di moduli arbitrari specificati tramite XSettings.
Ciò può infrangere i confini dell’applicazione.
Il nuovo Mir è progettato contro il keyboard/mouse sniffing. Le applicazioni non hanno la
possibilità di creare tastiere virtuali o sniffare tasti premuti durante l’esecuzione di altre applicazioni. Lo scatto di screenshot è proibito quando il focus è su un’altra applicazione. Clipboard,
drag and drop e casi speciali come testiere on screen di terze parti sono gestiti attraverso meccanismi di sicurezza connessi con AppArmor. Questo permette a Mir di, ad esempio, chiedere
ad AppArmor se un’applicazione può aver accesso alla clipboard. Le applicazioni in foreground, di default, hanno accesso alla clipboard di Mir, mentre questo è vietato ai processi non
36
user-facing24 . Mir non supporta XSettings a livello di applicazione. In altre parole è possibile accedere alle impostazioni tramite la shell, mentre le applicazioni non possono accedervi,
modificarle, o impostare il caricamento di moduli esterni.
2.10.3
Environment variables
Molte librerie consentono di avere comportamento diverso impostando alcune variabili d’ambiente prima di essere avviate. Ad esempio, GTK25 permette di specificare moduli arbitrari
da essere caricati impostando la variabile di ambiente GTK MODULES. Per questo motivo,
sarebbe meglio che le variabili d’ambiente fossero ispezionate prima dell’avvio di processi che
devono essere eseguiti confinati, in quanto ciò potrebbe essere utilizzato per violare i confini.
La soluzione adottata consiste nel cosiddetto Environment scrubbing, ovvero la rimozione di
varie variabili d’ambiente considerate pericolose prima dell’avvio di un eseguibile confinato [36]
[32].
2.10.4
Segnali tra processi
Nelle versioni precedenti a Ubuntu 14.04 LTS ogni applicazione poteva inviare un segnale ad
ogni altra applicazione in esecuzione, come il segnale TERM che causa la terminazione di
un processo. Attualmente, come visto nell’esempio in 2.5.3, il profilo AppArmor deve poter
specificare quali segnali un’applicazione confinata può inviare agli altri processi.
2.10.5
Protezione da remoto
A differenza di Android e iOS, Ubuntu Touch non ha a disposizione un sistema di protezione
da remoto built-in che consenta di bloccare il dispositivo, localizzarlo o cancellarne i dati.
Attualmente è possibile avere questa funzionalità con applicazioni di terze parti come Prey
[37]. Tuttavia, l’efficacia di una soluzione basata solo su software è molto discutibile nel nostro
caso. È vero che il sistema può supportare applicazioni preinstallate che non possono essere
rimosse dall’utente, tuttavia, se si collega il dispositivo a un computer via USB e si utilizzano
gli strumenti di sviluppo di Android, il device può ad ogni modo essere totalmente resettato. Al
momento, dunque, sembra non esserci soluzione lato sistema operativo. Ogni tipo di supporto
anti ladro deve essere implementato a basso livello dai produttori dell’hardware.
2.10.6
Certificati
Ubuntu Touch memorizza i certificati all’interno di file situati nella cartella /usr/share/cacertificates. L’estensione di questi file è .crt, e il formati dei certificati è PEM. Per ragioni di
sicurezza, a differenza della versione desktop, questa cartella è di sola lettura, dunque non è
possibile installare manualmente certificati auto firmati.
24
Processi non al momento visualizzati a schermo
GTK+, detto anche GIMP Toolkit, è un toolkit multi piattaforma per la creazione di interfacce utente
grafiche.
25
37
2.11
Vulnerabilità note
Per Ubuntu Touch si utilizza lo stesso database di CVE utilizzato per Ubuntu. Tale database
mostra le diverse vulnerabilità note, specificandone i livelli di criticità e il package corrispondente. È inoltre possibile visualizzare come il livello di criticità sia differente nelle diverse versioni
di Ubuntu. Il database è accessibile all’indirizzo: http://people.canonical.com/~ubuntusecurity/cve/.
2.12
Conclusioni
Sebbene possa apparire come un semplice nuovo sistema operativo mobile dall’interfaccia stile
Ubuntu, si è visto come in realtà Ubuntu Touch nasconda una grande innovazione. L’intento
di realizzare una soluzione software congiunta in grado di adattarsi contemporaneamente a
smartphone, tablet e desktop ha portato con se la necessità di sviluppare un modello di sicurezza
adatto a tale contesto.
Con più di 15 anni di storia alle spalle, AppArmor rappresenta uno strumento che ha maturato
l’esperienza necessaria per farsi carico di buona parte di questo difficile compito. Si è visto
come il suo funzionamento si basi sulla prevenzione, e non richieda un continuo processo di
scanning del sistema che minerebbe l’autonomia del dispositivo.
La definizione del confinamento di un’applicazione, già più semplice in AppArmor rispetto a
altre soluzioni quali SeLinux, è stata ulteriormente semplificata con i Policy Groups. Affiancando a ciò un potente SDK, si è riusciti a rendere questo strumento immediatamente accessibile
ai nuovi sviluppatori.
Dal punto di vista dell’utente, i Trusted Helpers forniscono, tramite messaggi di avviso come
Consentire all’applicazione di accedere alla fotocamera?, massima trasparenza sui permessi
concessi a un’applicazione. Essi permettono inoltre di revocare le autorizzazioni in un secondo
momento, opzione non presente in un diffuso sistema come Android.
Il sistema semi automatizzato di revisione delle nuove App consente tempi brevissimi di pubblicazione di nuovo software e può essere utile per portare sui device aggiornamenti di sicurezza
delle applicazioni in breve termine. Per essere approvate in automatico, le App devono rispecchiare requisiti di sicurezza molto restrittivi che ne assicurano l’innocuità nei confronti del
sistema: nel caso peggiore, il confinamento garantisce che i danni di un attacco siano limitati
al campo di azione della App stessa.
Condividendo con Ubuntu Desktop l’architettura generale, il sistema può beneficiare dei suoi
aggiornamenti di sicurezza.
Infine, trattandosi di un sistema open source, vanta la possibilità di beneficiare del contributo di
una vastissima community, importante mezzo per la scoperta e correzione di falle di sicurezza.
Si conclude l’analisi con alcune osservazioni critiche.
• In quanto nuovo sistema operativo in un mercato governato dai colossi Android e iOS, uno
degli obiettivi primari dello sviluppo di Ubuntu Touch è incentivare lo sviluppo di applicazioni, e il modo migliore per riuscirci è renderlo il più semplice possibile. Questo giustifica
l’uso dei Policy Groups nei Click packages. Tuttavia, non poter specificare manualmente
un profilo AppArmor per i Click package potrebbe essere in futuro una limitazione. Al
momento, infatti, tutti i permessi AppArmor richiesti da un’applicazione devono avere
un corrispondente in un Policy Group. Tale modello potrebbe collassare di fronte alla
38
necessità di avere un modello di sicurezza più complesso che permetta di definire il confinamento con più dettaglio. Naturalmente, si perderebbe il vantaggio di una revisione
automatica dell’applicazione da parte dello store. Per questo, una soluzione potrebbe essere concedere la possibilità allo sviluppatore di definire profili AppArmor manuali per i
propri Click package a patto che essi siano revisionati manualmente, eventualmente sotto
pagamento di una commissione.
• Al momento il confinamento delle applicazioni è fatto su due livelli: AppArmor e Trusted
Helper. Nel momento in cui un Trusted Helper memorizza un certo permesso concesso
dall’utente, l’applicazione in questione può accedere (da lı̀ in avanti) a una determinata risorsa prima proibita. In tutto ciò, il profilo AppArmor è rimasto invariato. Esso
semplicemente dichiara la possibilità per quell’applicazione di comunicare con lo specifico Trusted Helper, ma non contiene informazioni riguardo la scelta dell’utente. Questo
meccanismo fa si che il profilo AppArmor non sia sufficiente per determinare i privilegi
di un’applicazione. Sarebbe meglio che tali informazioni fossero concentrate in un unico
punto. Ad esempio si potrebbe estendere AppArmor al fine di memorizzare in un profilo
anche le definitive autorizzazioni concesse dell’utente. In tal caso dovrebbe essere capace
di modificare dinamicamente il profilo in funzione di esse.
• Al fine di non impattare l’autonomia del dispositivo, non è presente un sistema di monitoring costante delle risorse utilizzate dai processi. Inoltre, condividendo l’architettura
con Ubuntu desktop, non si ha ancora un sistema di gestione ottimizzata dei processi in background: in altre parole, come su Ubuntu Desktop, è concessa l’esecuzione in
background senza limitazione di risorse. In questo modo un’applicazione intenzionata a
saturare le risorse del dispositivo in termini di CPU o a scaricare la batteria, potrebbe
superare automaticamente i controlli di sicurezza dello store e portare a termine il suo
scopo.
39
3
CyanogenMod
Figura 11: Schermata di home di CyanogenMod
3.1
26
.
Modalità dell’analisi di sicurezza
In questo capitolo verranno analizzati alcuni aspetti di sicurezza di CyanogenMod. Si tratta
di una Mod di Android, il diffuso sistema operativo di Google. Il termine “Mod” significa
che si tratta di una nuova versione dello stesso software, con alcune modifiche che permettono
maggiore personalizzazione e funzionalità aggiuntive. Per questo motivo, saranno analizzati in
particolare gli aspetti che lo distinguono da Android e che si trovano principalmente a livello di
applicazione. Si è deciso di non analizzare la sicurezza di basso livello in quanto essa coincide
con quella di Android ed esula pertanto dagli scopi di questo report. Le informazioni qui
riportate provengono in gran parte da ricerche online anche al di fuori della Wiki ufficiale.
CyanogenMod conta molto sull’informazione generata e trasportata dalla community, pertanto
la documentazione “ufficiale” è molto scarsa. Al fine di accertare le informazioni trovate, sono
state effettuate prove manuali su dispositivi reali.
26
Sorgente immagine:
cyanogenmod-12/.
http://crysweb.altervista.org/2015/02/19/android-lollipop-su-oneplus-one-con-
40
3.2
Introduzione
3.2.1
Storia
Poco dopo il rilascio del telefono cellulare HTC Dream (conosciuto come “T Mobile G1” negli
Stati Uniti) nel settembre 2008, fu scoperto un sistema per ottenere un controllo di amministrazione (conosciuto come “accesso root”) al sistema Linux sul quale si basa Android. Avere
l’accesso root, combinato alla natura open source del sistema operativo Android, ha permesso
al firmware originale del telefono di essere modificato e re-installato sul telefono stesso. Negli anni successivi molti firmware modificati furono sviluppati e distribuiti da appassionati di
Android. Uno, mantenuto da uno sviluppatore chiamato JesusFreke, presto diventò popolare
tra i possessori del Dream. Nell’agosto 2009 JesusFreke smise di lavorare al suo firmware e
suggerı̀ agli utenti di passare a una versione della sua ROM che era stata ulteriormente migliorata dallo sviluppatore Cyanogen (Steve Kondik), chiamata “CyanogenMod”. La popolarità
di CyanogenMod crebbe rapidamente e una piccola comunità di sviluppatori, conosciuta come
CyanogenMod Team, contribuı̀ al progetto. Nel giro di pochi mesi il numero di dispositivi e
di funzionalità supportate da CyanogenMod aumentò e CyanogenMod diventò in poco tempo
una delle distribuzioni di firmware Android più popolari [38].
3.2.2
Differenze con Android
CyanogenMod offre caratteristiche e opzioni non disponibili nel firmware ufficiale distribuito
dai vendor di questi devices, come nuovi temi grafici, il supporto per codec audio FLAC27 ,
CPU overclocking, gestione dei permessi delle app, un client OpenVPN, root access ed altri
ancora. Se queste caratteristiche fanno pensare semplicemente a un sistema operativo che offre
all’utente più funzioni e maggiore personalizzazione, si sottolinea anche che la progettazione
di CyanogenMod è volta a migliorare le performance, affidabilità e sicurezza dei dispositivi.
Come vedremo successivamente, queste caratteristiche positive portano con sé un rovescio della
medaglia. Fornire maggiori funzionalità all’utente significa anche dargli maggiori permessi
e, potremmo dire, maggior fiducia. Un utente inesperto potrebbe inconsciamente minare la
sicurezza del proprio dispositivo, molto più facilmente che su sistemi più “chiusi” quali ad
esempio iOS [39].
3.2.3
Distribuzione
Secondo le nostre informazioni, al momento CM è distribuito come sistema operativo nativo
solo sullo smartphone OnePlus One. Per gli altri dispositivi, è da intendersi come un sistema
operativo installabile in sostituzione di quello già presente. Il 6 Gennaio 2015 è stata rilasciata
l’ultima versione: CyanogenMod 12. Il firmware è rilasciato in diverse varianti: Stable, Release
Candidate e Nightlies. La versione Stable, come lo stesso nome suggerisce, è quella maggiormente testata, conforme agli standard (informali) di sicurezza e stabilità che la comunità degli
sviluppatori si impone. Release Candidate è la fase subito precedente alla Stable: si tratta di
una versione che non presenta bug o vulnerabilità fatali, ma che non è ancora stata testata
completamente. Infine, le Nightlies sono piccoli aggiornamenti molto poco testati, rilasciati a
distanza di poche ore l’uno dall’altro, e per questo motivo sconsigliati all’utente medio [40].
27
Free Lossless Audio Codec è un formato di codifica audio che non comprime l’audio digitale.
41
3.2.4
Device Rooted
Il termine root indica il processo di acquisizione dei diritti di superuser all’interno di un sistema
Linux o suo derivato, come Android. Il superuser possiede privilegi di amministratore, pertanto
è in grado di accedere ad ogni dato all’interno del sistema e di eseguire operazioni potenzialmente
pericolose per la stabilità e sicurezza del sistema stesso. I sistemi Linux desktop permettono
di ottenere privilegi di amministratore semplicemente attraverso la shell. La maggior parte dei
sistemi operativi mobili Linux-based, essendo progettati per un’ampia utenza di competenza
medio-bassa e facendosi carico delle problematiche di sicurezza trattate nell’introduzione di
questo report, adottano invece una strategia più restrittiva, in cui all’utente sono fortemente
limitate operazioni sensibili sul sistema. Il root (o rooting) viene spesse eseguito con lo scopo
di superare queste limitazioni, imposte generalmente dagli operatori telefonici o dal produttore
dell’hardware. Il rooting da l’abilità (o il permesso) di modificare o sostituire applicazioni
preinstallate e impostazioni di sistema, avviare particolari applicazioni che richiedono permessi
di amministratore, avere accesso di basso livello all’hardware, o eseguire altre operazioni che
sono di norma inaccessibili a un normale utente Android [41].
Come ogni Mod che si rispetti, e al fine di rendere possibili molte delle caratteristiche vantaggiose che lo contraddistinguono dallo standard Android, CyanogenMod è in grado di fornire
all’utente e alle applicazioni privilegi di amministratore (privilegi di root). Come già accennato,
ai vantaggi suddetti si affiancano diversi svantaggi: ottenere accesso root significa anche poter
aggirare le restrizioni di sicurezza standard del sistema operativo. Il che significa che worms,
virus, spyware e trojan possono infettare il dispositivo, se non è protetto in altro modo (lo
vedremo nella sezione 3.3.3). Ci sono diversi modi tramite cui questi malware possono infettare
il proprio telefono o tablet: web downloads, link malevoli, applicazioni infette scaricate da altri
app store. Software malevolo eseguito con privilegi di amministratore può avere accesso ad ogni
dato contenuto nel dispositivo.
3.3
3.3.1
Tecniche di confinamento delle applicazioni
Il modello Android
Il modello di sicurezza di CyanogenMod realizza il confinamento delle applicazioni allo stesso
modo di Android, riutilizzando il sistema nativo del Linux Kernel di gestione dei permessi
utente. Nei sistemi Linux desktop, ad ogni utente è associato un identificativo univoco (UID
- User Id) che è poi utilizzato per specificare i permessi di accesso a file e cartelle: ogni file
e cartella contiene una lista di UID, e per ognuno dei quali sono indicati i permessi (Lettura,
Scrittura, Esecuzione). Android riutilizza questo sistema considerando le applicazioni come
utenti e assegnando a ognuna di esse un diverso UID. In questo modo, ogni applicazione può
accedere solamente ai file di sua proprietà, o eventualmente alle risorse di altre applicazioni
per cui è stato esplicitamente consentito l’accesso. Come già detto, poiché l’analisi di Android
esula dagli scopi di questo report, non si scende nei dettagli implementativi di questa soluzione.
Per una discussione più approfondita si rimanda a [42]. L’autorizzazione ad utilizzare risorse
quali GPS, Fotocamera, Contatti, Risorse ecc... viene richiesta al momento dell’installazione:
l’utente può visualizzare l’elenco dei privilegi richiesti e decidere se accettarli e proseguire
con l’installazione, oppure rifiutarli e annullare. Android non presenta ad oggi una soluzione
per concedere all’utente di personalizzare i permessi di una applicazione o rimuovere specifici
privilegi concessi al momento dell’installazione.
42
Figura 12: Schermata di esempio di Privacy Guard
3.3.2
28
.
Gestione dei permessi
CyanogenMod, pur condividendo con Android la soluzione basata sugli UID per il confinamento
delle applicazioni, offre una funzione in grado di permettere all’utente di revocare selettivamente
ad una applicazione i permessi concessi al momento dell’installazione. Tale funzione è realizzata
tramite l’applicazione built-in Privacy Guard. Privacy Guard è presente in CM a partire dalla
versione 10 e, oltre a quanto detto, consente anche di selezionare quali applicazioni debbano
essere avviate automaticamente al bootup del dispositivo. È stata realizzata con l’intento di
portare la gestione della privacy anche nelle mani dei meno esperti, pertanto, oltre ad un
menù avanzato per ogni applicazione, fornisce anche la possibilità di semplicemente attivare o
disattivare il profilo Privacy Guard per una specifica App, impostando un profilo di sicurezza
di default [43].
Privacy Guard è stato realizzato sulla base di App Ops. App Ops era una funzionalità già
presente in versioni precedenti e nascosta, scoperta per la prima volta in Android 4.3. Il suo
scopo era quello di permettere agli utenti di disabilitare specifici permessi alle applicazioni dopo
l’installazione. In realtà App Ops non fu mai pensato come uno strumento per gli utenti, ma
solo per scopi di debugging [44]. È stato rimosso nelle build di Android successive alla 4.3.
Privacy Guard è ora l’“App Ops” di CyanogenMod a partire dalla versione 10 [45]. Non è da
escludere che gli sviluppatori di CM possano aver riutilizzato parte del codice della vecchia App
Ops di Google, forse avendone anche a disposizione il sorgente intero.
CyanogenMod ha dunque integrato App Ops in modo che gli utenti possano individualmente
impostare su on o off i permessi per la localizzazione, la lettura dei contatti e dei log delle
chiamate, la lettura del calendario, permessi su SMS/MMS ecc... per ciascuna app installata.
È stata aggiunta anche la possibilità di ricevere notifiche nel momento in cui una App tenta di
accedere ad una risorsa bloccata. L’ultimo accesso consentito viene memorizzato e può essere
visualizzato. Poiché la rimozione dei permessi ad una applicazione non è normalmente possibile,
tale operazione potrebbe minare la stabilità dell’applicazione interessata.
28
Sorgente immagine:
with-cm10-2-20130925/.
http://androidcommunity.com/cyanogenmod-privacy-guard-updated-and-merged-
43
3.3.3
Gestione privilegi di root
In passato, per poter utilizzare CyanogenMod, era necessario provvedere manualmente alla sua
installazione su un dispositivo supportato, al posto del precedente sistema operativo Android.
Eseguire questa operazione richiedeva competenze non comuni e rappresentava pertanto una
difficoltà in grado di selezionare l’utenza di CM. A seguito di ciò, CM era utilizzato prevalentemente da individui mediamente coscienti dei rischi legati alle nuove potenzialità fornite dal
sistema operativo e, in generale, all’uso di un device rooted. Ad oggi, invece, eseguire il rooting
è molto più semplice, grazie all’uso di tool appositi e ad una vastissima documentazione in rete.
Ciò ha reso questa Mod di Android alla portata di una gamma di utenti sempre più vasta.
Inoltre, come già accennato in precedenza, proprio in questi mesi si sta assistendo all’arrivo sul
mercato dei primi dispositivi venduti con CM già installato. Ciò fa capire come CM non sia più
considerabile un sistema operativo di nicchia, riservato ad un’utenza mediamente competente,
bensı̀ lo si trova nelle mani di chi, incosciente dei rischi di sicurezza associati, lo vuole sfruttare
per provare funzionalità normalmente vietate.
Per queste ragioni, la 11 è l’ultima versione di CM ad essere rooted di default. In CM11 in
teoria tutte le applicazioni possono eseguire operazioni con privilegi di root. In pratica, la
sicurezza viene implementata a livello di applicazione: applicazioni di terze parti, tra le quali
spicca Superuser, si occupano di permettere all’utente di gestire quali applicazioni possano
ottenere i privilegi di amministratore. A partire da CM12, invece, di default il device non è
rooted. L’arricchimento delle API fornite dal sistema operativo rispetto ad Android è in grado
di permettere a molte applicazioni di fornire nuove funzionalità pur non avendo bisogno dei
privilegi di root [46].
Tuttavia, in CM12 è comunque possibile abilitare il root del dispositivo. È curioso notare come,
al fine di evitare che un utente attivi inconsciamente il root, tale opzione sia stata nascosta: è
necessario recarsi in “Settings”-¿“About phone” e toccare “Build number” più volte29 . Il root
può essere attivato in 3 modalità distinte:
• Solo per le App;
• Solo per l’ADB30 ;
• Per entrambi.
Una volta che il root per le App è attivato, all’interno delle impostazioni di Privacy Guard per
ciascuna applicazione, apparirà una nuova opzione che, come Superuser in CM11, permetterà
di dare singolarmente a ciascuna applicazione il permesso di eseguire azioni con privilegi di
root.
Privacy Guard è in grado di intercettare le richieste delle applicazioni di eseguire il comando
su, che permette di elevare i propri privilegi a quelli di superutente, ovvero amministratore,
e di dare all’utente, tramite la visualizzazione di un messaggio, la possibilità di autorizzare
o meno l’operazione. Per vedere questo meccanismo più nel dettaglio, si consideri il caso di
un’applicazione che esegue la seguente riga di codice:
Process p = Runtime.getRuntime().exec(‘‘su’’);
29
Le ragioni di questa scelta risiedono con ogni probabilità nel fatto che per scoprire tale funzionalità è
necessaria una ricerca in rete, che presume un minimo livello di informazione al riguardo
30
Android Debug Bridge, è uno strumento a riga di comando per sistemi desktop che permette di comunicare
con un dispositivo android connesso.
44
Tale riga causa la pubblicazione di un Intent 31 , all’interno del gestore dei messaggi di Android,
che richiede a Privacy Guard di confermare o meno l’operazione. La scelta dell’utente viene
salvata per i futuri utilizzi e resta modificabile attraverso il pannello di controllo di Privacy
Guard.
3.4
Store
Poiché CyanogenMod sfrutta lo stesso App store di Android, Google Play, non tratteremo in
dettaglio le sue caratteristiche di sicurezza. Google Play prevede che le applicazioni siano firmate dagli sviluppatori e sottoposte a un processo di revisione in parte manuale e in parte
automatico. È importante sottolineare che, nel caso di CyanogenMod, la sicurezza a livello
di store non ha grande effetto sulla sicurezza finale del dispositivo. Infatti, una delle funzionalità più utilizzate degli utilizzatori di questo sistema operativo è la possibilità di installare
applicazioni da fonti diverse dallo store “ufficiale”. Tali applicazioni spesso richiedono privilegi
speciali (di root) per fornire quelle funzionalità aggiuntive che l’utente medio di CyanogenMod
desidera. Del resto, come detto nell’introduzione, questo è il concetto base attorno a cui ruota
questo sistema operativo. Per questo motivo, la sicurezza è molto più nelle mani dell’utente,
che deve gestire manualmente privilegi speciali, piuttosto che nei meccanismi attuati a livello
di store.
3.5
3.5.1
Componenti di sicurezza aggiuntivi
Whisperpush
Gli sviluppatori di CyanogenMod hanno lavorato per lungo tempo all’integrazione nel proprio
firmware di un servizio di messaggistica sicura, fino a riuscire ad introdurlo per la prima volta
ufficialmente in CM11. Si chiama Whisperpush e si basa su TextSecure, un client open-source
cross-platform (iOS e Android) che cifra gli SMS sia localmente che durante l’invio ad altri
utenti TextSecure. Questa funzionalità, sul modello di iMessage utilizzato nei sistemi iOS, una
volta abilitata è totalmente trasparente all’utente. Nel momento in cui si invia un messaggio
attraverso l’applicazione nativa per gli SMS, il sistema controlla se il destinatario possiede un
client TextSecure (sia esso un dispositivo Android o iOS) e, in caso affermativo, provvede alla
cifratura del messaggio e al suo invio attraverso il canale dati, altrimenti esso viene inviato
come normale SMS. Il dispositivo che riceve il messaggio cifrato provvederà alla sua decifratura
e a mostrarlo all’interno dell’applicazione nativa per gli SMS. Tutto ciò è totalmente nascosto
all’utente, a cui non è richiesto di eseguire uno scambio di chiavi, o di sapere che il ricevente è
“online”.
Il protocollo TextSecure nasce come una modifica del protocollo OTR (off the record messaging
protocol), che usa chiavi effimere concordate tramite l’algoritmo Diffie-Hellman a curva ellittica.
L’utilizzo di chiavi effimere è utile perché usare sempre la stessa chiave pubblica può nel tempo
aumenta la probabilità che sia scoperta. In tal caso, sarebbe inoltre possibile decifrare tutti
i messaggi inviati precedentemente con chiunque. La modifica del protocollo OTR è stata
necessaria per adattarlo ad un ambiente mobile, dove fattori come lo stato della rete e i vincoli
legati al risparmio energetico richiedono che la messaggistica sia di natura asincrona. In sostanza
si è dovuto gestire il caso in cui la controparte non sia al momento raggiungibile (vuoi perché
non ci sia copertura di rete o perché il sistema operativo non gli permetta di essere eseguita in
31
Un Intent è un oggetto di messaggistica che può essere utilizzato per richiedere un’azione a un’altra
applicazione.
45
background). Poiché Diffie-Hellman richiede ovviamente uno scambio di messaggi, per adattarlo
a questo contesto asincrono è stata utilizzata la soluzione che è descritta di seguito.
Dettagli del funzionamento del protocollo TextSecure:
1. Alla prima connessione al server, un client TextSecure, che si vuole chiamare A, genera
preventivamente 100 messaggi per lo scambio chiavi Diffie-Hellman e li invia al server. Si
chiamino questi “premessaggi”. La curva ellittica utilizzata è Curve25519.
2. Un nuovo client B, che vuole inviare ad A un messaggio sicuro, può ora connettersi al
server e eseguire l’algoritmo Diffie-Hellman scaricando da esso i premessaggi inviati da A.
3. In questo modo B ottiene il segreto condiviso e lo può utilizzare per inviare al server
il messaggio cifrato, insieme ai propri messaggi per il key agreement. I messaggi sono
cifrati utilizzando un cifrario AES in modalità CTR, con una chiave a 256 bit. Il server,
non essendo a conoscenza del segreto di A utilizzato per generare i premessaggi, non è in
grado di decifrare il messaggio.
4. Nel momento in cui A si collegherà al server potrà scaricare il messaggio cifrato di B e,
avendo mantenuto in memoria i premessaggi inviati al server, ricavare la chiave condivisa.
3.5.2
Protezione da remoto: Device Finder
Da qualche anno, Google ha introdotto per i dispositivi Android il servizio “Android Device
Manager”. Si tratta di un servizio online che da la possibilità agli utenti di eseguire da remoto
operazioni sul proprio device, principalmente a scopi di sicurezza. È possibile ad esempio bloccare il proprio device con una nuova password, oppure eseguirne il wipe, ovvero la cancellazione
di tutti i dati contenuti. Android device Manager consente inoltre di rintracciare il proprio
dispositivo, se dotato di GPS.
Gli sviluppatori di CyanogenMod hanno risposto alla soluzioni di Google con “Device Finder”.
Dal punto di vista delle funzionalità offerte si tratta di un servizio del tutto simile all’Android
Device Manager, ma che presenta grandi differenze nella sua implementazione, volte a garantire
massima sicurezza e riservatezza agli utenti [47].
Quando si utilizza Android Device Manager per rintracciare il proprio dispositivo, è necessario
autenticarsi utilizzando il proprio Account Google su un’apposita pagina web (www.google.
com/android/devicemanager). Da questo, si invia al server Google la richiesta di interrogare
il proprio smartphone riguardo la propria posizione. Il server Google rintraccia il dispositivo
grazie a un servizio, Google Play Services, che opera silenziosamente su di esso. Il nostro
device Android è progettato per fidarsi del server Google, pertanto risponde inviando la propria
posizione. Infine, il server Google passa questa posizione al nostro browser, dove è possibile
visualizzarla.
Come si può notare, il server Google agisce da intermediario. Esso vede le informazioni trasmesse in chiaro. Teoricamente potrebbe personificare una persona e chiedere al nostro device
la sua posizione in qualsiasi momento lo desideri. Potrebbe essere che qualcuno al di fuori
del proprietario utilizzi il server Google per avere la nostra posizione, magari in seguito ad
accordi commerciali. Ovviamente è noto che Google promette di non rivelare le nostre informazioni, ma in questo modo la nostra sicurezza consiste appunto nel fidarsi di Google, e non
nell’implementazione del sistema stesso [48].
Il servizio CyanogenMod Device Finder disponibile all’interno di CyanogenMod Accounts crea
invece un canale di comunicazione sicuro tra il browser e il dispositivo, in cui il server svolge solo
46
Figura 13: Confronto tra il reperimento della localizzazione del dispositivo tramite l’Android
Device Manager o CyanogenMod Device Finder. In rosso si hanno le comunicazioni cifrate
con la chiave simmetrica scambiata.
il ruolo di intermediario, incapace di leggere il contenuto delle informazioni sensibili trasmesse.
SI analizza nel dettaglio.
1. L’utente si autentica su account.cyanogenmod.org attraverso connessione sicura HTTPS,
utilizzando la propria password. La password in chiaro non viene inviata al server, ne
viene inviata una sua derivata.
2. Nel momento in cui viene richiesta la posizione del device, il browser genera una coppia
chiave pubblica/privata, esegue l’HMAC della pubblica utilizzando la password dell’utente
(non nota al server), e invia al server la chiave pubblica insieme all’hash calcolato.
3. Il server riceve questo messaggio e lo ritrasmette al device.
4. Il device, conoscendo la password dell’utente (impostata in precedenza), autentica il messaggio contenente la chiave pubblica, genera una chiave simmetrica e la manda al server,
cifrata tramite la chiave pubblica appena ricevuta.
5. Il server trasmette il messaggio al nostro browser. Il server non è in grado di leggere la
chiave simmetrica contenuta all’interno del messaggio cifrato in quanto non è in possesso
della chiave privata per decifrarlo.
6. Il nostro browser, che invece conosce la chiave privata ottenuta nel passaggio 2, decifra il
messaggio e ottiene la chiave simmetrica.
7. Da questo momento in avanti, browser e device possono comunicare attraverso un canale
sicuro protetto con tale chiave asimmetrica. Il server farà sempre da intermediario, ma
non potrà decifrare i contenuti in transito.
La sicurezza di questo sistema consiste nella sua implementazione, non nella fiducia verso
qualcuno o qualcosa. Quando il nostro dispositivo invia la propria posizione, nessun agente nel
mezzo può leggerla. Nessuno può iniziare il rintracciamento se non il proprietario. Nessuno
47
può pagare o accordarsi con gli operatori del server affinché rintraccino il dispositivo senza il
nostro consenso.
Si ricorda che aziende come Google e Apple, se da una parte vogliono vendere i propri prodotti
come sicuri per attirare gli utenti, dall’altra hanno interessi a non proteggere la loro privacy.
Questo tipo di interesse non è invece riscontrabile in CyanogenMod, non essendo un prodotto
a scopo di lucro.
3.6
Cifratura dati utente
La cifratura è utilizzata per garantire la riservatezza dei dati memorizzati su un dispositivo in
caso della perdita o furto dello stesso.
In CyanogenogenMod, le possibilità di cifratura offerte sono ereditate da Android. In questo,
la cifratura per proteggere i dati è disponibile soltanto dalla versione 3.0 (Honeycomb) in su.
Per abilitare la cifratura su un dispositivo Android il filesystem deve essere montato su un
dispositivo che presenta un interfaccia block device32 . La cifratura è effettuata con dm-crypt
e, sebbene si parli di disk encryption, in realtà non è eseguita sull’intero disco (in quanto
renderebbe impossibile il boot) ma solo sulla cartella
data, contenente tutti i dati utente e delle applicazioni.
Dm-crypt è un sistema per la crittografia dei dati utilizzato nel Kernel linux a partire dalla
versione 2.6. Esso è parte dell’infrastruttura “device mapper”, ovvero quella che si occupa della
mappatura dei dati tra unità virtuali di archiviazione di massa (come viste e utilizzate dalle
applicazioni) e effettivo hard disk fisico. La crittografia dei dati avviene in modo trasparente
al resto del sistema proprio nel corso di questa mappatura [50]. Una volta che il disco è cifrato,
ogni dato creato dalle applicazioni viene automaticamente cifrato prima che sia scritto su di
esso e tutti i dati letti da disco sono automaticamente decifrati prima di essere ritornati al
processo che li richiede.
Dm-crypt utilizza AES-128 con CBC e ESSIV SHA 256 33 . La chiave di cifratura è memorizzata
sul disco in modo sicuro secondo un processo che coinvolge sia la password dell’utente sia
una chiave memorizzata in hardware nel dispositivo (hardware-bound private key, HBK)34 . Si
mostra tale processo nel dettaglio:
1. In modo casuale viene generata una disk encryption key (DEK) di 128 bit e un sale della
stessa lunghezza. Questa prima fase è eseguita solo la prima volta che si attiva la cifratura
del disco.
2. Si applica scrypt 35 alla password dell’utente e al sale della fase precedente per produrre
una chiave intermedia IK1 di 256 bit.
32
Un dispositivo a blocchi (in lingua inglese block device), nei sistemi operativi Unix e Unix-like, è un dispositivo su cui è possibile effettuare operazioni di input/output per blocchi di byte di dimensione predeterminata
(tipicamente dispositivi di memoria di massa come i dischi rigidi).[49]
33
ESSIV è un metodo per generare vettori di inizializzazione per cifratura a blocchi utilizzata nella cifratura
di dischi di memoria. ESSIV genera i vettori di inizializzazione da una combinazione del numero di settore del
disco da cifrare e l’hash della chiave di cifratura [51].
34
Parliamo di una TEE key. TEE è acronimo di Trusted Execution Environment ed è una area sicura del
processore di un dispositivo che fornisce funzionalità di sicurezza
35
Scrypt è una key derivation function. Come PBKDF2, già vista in 2.8, serve per derivare un segreto, nel
nostro caso IK1 e IK3, a partire da un altro segreto, nel nostro caso la password dell’utente e IK2. A differenza
di PBKDF2, scrypt è più sicura contro attacchi brute-force implementati in hardware.
48
3. A IK1 viene aggiunto del padding per portarlo alla lunghezza della HBK citata precedentemente.
4. Il risultato dell’operazione precedente è firmato utilizzando HBK per produrre IK2, di
256 byte.
5. Si applica nuovamente scrypt a IK2 utilizzando lo stessso sale della fase 2 per produrre
IK3, di 256 bit.
6. I primi 128 bit di IK3 sono utilizzati come KEK (key encryption key) e gli ultimi 128
come vettore di inizializzazione IV.
7. DEK viene cifrata utilizzando AES CBC con chiave KEK e vettore di inizializzazione IV.
Si noti che l’utilizzo di HBK, introdotto solo dalla versione 5 di Android, aggiunge ulteriore
protezione contro attacchi “off the box” in cui l’hard disk è estratto dal dispositivo.
Il lettore potrebbe chiedersi perché la DEK sia generata in modo casuale invece che direttamente
derivata dalla password utente. La risposta risiede nel fatto che se cosı̀ fosse fatto, cambiare la
password utente richiederebbe di decifrare e ricifrare con la nuova DEK corrispondente tutti i
dati già cifrati. Nel modo sopra illustrato, al contrario, è sufficiente decifrare la DEK e ricifrarla
con la nuova KEK [52].
3.7
Protezione dell’accesso
Figura 14: Esempio di Lock Pattern
36
.
Il controllo di accesso tradizionale consiste in una sistema di sicurezza che consente l’accesso al
dispositivo solo a chi conosce un segreto preimpostato. Tale segreto, richiesto per sbloccare il
dispositivo dalla condizione di standby, può essere in forma di:
36
Sorgente immagine http://automagic4android.com/.
49
• Lock Pattern. Si tratta di uno specifico percorso su una griglia di punti 3 X 337 . Lo
svantaggio è che se il display trattiene facilmente le impronte lasciate dalle dita, potrebbe
essere facile recuperare il percorso. Si consigliano pertanto percorsi non troppo semplici.
È mostrato in Figura 14.
• Codice PIN. È una sequenza di cifre. Il numero di cifre va da 4 a 17.
• Password alfanumerica. È la password classica alfanumerica. È sicuramente il sistema
più sicuro, ma richiede generalmente più tempo per l’inserimento.
3.8
Conclusioni
In origine, CyanogenMod rappresentava un sistema operativo accessibile ad un’utenza relativamente esperta. Ciò ha permesso per anni di trascurare alcune problematiche di sicurezza,
secondo un modello di fiducia verso l’utente. Indubbiamente si trattava di un sistema più pericoloso (si pensi al root abilitato di default), ma ciò era in un certo senso il prezzo da pagare
per poter usufruire di certe potenzialità.
La sua recente crescente diffusione, unita a un diffuso innalzamento degli standard di sicurezza richiesti dal mercato, hanno portato gli sviluppatori ad ideare una soluzione in grado al
contempo di soddisfare la necessità di un sistema sicuro e le richieste di quella grossa fetta
di utenza amante del root. L’integrazione di superuser all’interno di Privacy Guard, insieme
ad un’impostazione di default che disabilita il root, rendono il sistema operativo utilizzabile in
modo sicuro anche dai meno esperti. Il sistema messo in pratica da Privacy Guard era divenuto
particolarmente necessario da quando, sapendo dell’incoscienza dell’utente medio nell’installare
applicazioni non fidate, tra gli sviluppatori è diventato di uso comune richiedere per la propria
app un lungo elenco di autorizzazioni. si trova infatti oggi sul Google Play Store applicazioni come la torcia, che richiedono il permesso di accedere ai nostri contatti o al profilo Facebook, e ciò
non sembra importare molto agli utenti. Ciò fa riflettere su quanto sia importante l’educazione
del pubblico alla sicurezza e su quanto ci sia ancora molto da fare.
Nel complesso, è possibile notare un grande passo avanti rispetto ad Android: la possibilità di
gestire in modo semplice ed intuitivo le singole risorse a cui le applicazioni possono accedere è
una pietra miliare nel cammino verso un sistema sempre più attento alla privacy degli utenti.
Purtroppo, poiché le applicazioni scaricabili su un dispositivo CyanogenMod sono le stesse
sviluppate per Android, esse non prevedono che i permessi possano essere revocati. In tal caso,
la stabilità dell’App è fortemente compromessa.
È importante sottolineare che l’intero codice di CyanogenMod è Open Source, scaricabile e
compilabile. Nonostante i più non abbiano le competenze per comprenderlo, ciò è un aspetto
importantissimo in termini di sicurezza. Avere accesso al codice consente alla comunità di
sviluppatori di setacciarlo alla ricerca di problemi da risolvere. Qualcuno potrebbe obiettare
che il codice open source è un’arma a doppio taglio: di fatto è vero, trovare falle di sicurezza
potrebbe anche consentire ad un attaccante di sfruttarle per scopi maligni. Tuttavia, si ricorda
che il codice dei nuovi moduli viene pubblicato nelle nightly build ben prima che sia inserito
all’interno delle stable release. In questo lasso di tempo, è probabile che eventuali vulnerabilità
siano scoperte. Per queste ragioni è consigliabile di installare solo le versioni stable.
Se da questo punto di vista le nightly build possono essere meno sicure in quanto non ancora
testate a sufficienza, dall’altro rappresentano un potente strumento per migliorare la sicurezza:
tramite queste, infatti, gli sviluppatori possono fornire agli utenti aggiornamenti rapidi contro
eventuali nuove vulnerabilità scoperte.
37
In alcune versioni è possibile modificare la dimensione della griglia
50
4
Tizen
Figura 15: Schermata Home di Tizen38
4.1
Modalità dell’analisi di sicurezza
L’analisi di sicurezza di Tizen è la combinazione di un’analisi documentale e sperimentale.
Sebbene la prima sia quella di maggiore consistenza, tramite alcuni test sperimentali è stato
possibile comprendere al meglio le tecniche impiegate nel sistema. Tizen attualmente viene
installato solo in alcuni dispositivi venduti nel mercato asiatico, per questo è stato possibile
eseguire i test solo nella versione virtualizzata del sistema operativo.
Lo sviluppo di Tizen è recente, ma la documentazione disponibile è ampia, soprattutto quella
a disposizione per gli sviluppatori39 ed il Wiki40 . Tuttavia le informazioni appaiono spesso
frammentarie ed è evidente la necessità di riorganizzazione. La continua evoluzione e le nuove
soluzioni proposte rendono spesso difficile il compito di analisi.
Nella ricerca di informazioni hanno rivestito grande importanza anche mailing list ufficiale ed
il materiale reso disponibile in occasione delle “Tizen Developer Conference”, sia nella forma
38
Sorgente immagine: https://en.wikipedia.org/wiki/Tizen#/media/File:Tizen screenshot en original.png
https://developer.tizen.org/documentation
40
https://wiki.tizen.org/wiki/Main Page
39
51
di audio che di presentazioni41 . In merito alla sicurezza di Tizen, esistono due pubblicazioni
[53] [54], anche se risultano sorpassate nei contenuti, a causa dei frequenti aggiornamenti dei
componenti di sicurezza del sistema operativo.
L’analisi segue lo schema logico definito in 1.3. Da notare che le sezioni su “Tecniche di
confinamento delle applicazioni” 4.5 e “Componenti di sicurezza aggiuntivi” 4.9 prevedono
alcuni paragrafi di commento da parte dell’autore del report. Inoltre, le tematiche riportate
in “WebGL” 4.6.2 e “XSS” 4.6.3 non trovano completo riferimento in fonti esistenti, ma sono
frutto di un processo di analisi critica delle soluzioni adottate. La sezione 4.12, invece, è
completamente dedicata all’esposizione dei risultati sperimentali.
4.2
Introduzione
Tizen è un sistema operativo open source per dispositivi Mobile, come smartphone e tablet,
Wearable e sistemi In-Vehicle Infotainment (IVI). In futuro, punta a diventare una piattaforma
open source per tutti i dispositivi dell’elettronica di consumo (netbook, TV, macchina fotografica, stampante, lavatrice). Per poter gestire la diversità dei sistemi supportati, Tizen utilizza
profili dedicati: configurazioni specifiche dello stesso sistemi operativo. L’analisi si concentra
sul profilo Mobile [55].
4.2.1
Tizen, “The OS of Everything”
Nell’era precedente gli smartphone, gli utenti erano abituati ad utilizzare dispositivi differenti
(cellulare, navigatore auto, macchina fotografica, TV) con la consapevolezza che le applicazioni, per quanto simili nelle funzionalità, differivano nell’usabilità. I produttori dei dispositivi
sviluppavano piattaforme proprietarie e specifiche per ciascun apparecchio. Oggi nel mondo
dell’“Internet of the Things”, le esigenze di connettività, compatibilità ed usabilità richiedono
un cambiamento nell’approccio allo sviluppo. Qui nasce l’idea alla base di Tizen: una piattaforma standard, utilizzabile in diverse categorie di dispositivi con pochi cambiamenti. Inoltre,
essendo open source, i produttori possono sviluppare con maggiore semplicità.
4.2.2
Storia
Nel 2010, Nokia ed Intel annunciarono MeeGo, un sistema operativo per le applicazioni Web,
basato su Linux. Nokia, in seguito, uscı̀ dal progetto, concentrandosi esclusivamente sullo
sviluppo di Windows Phone. Intel era ancora intenzionata a sviluppare un sistema operativo
ottimizzato per i propri processori, con l’intenzione di entrare nel crescente mercato mobile. Nel
2011, con il supporto della Linux Foundation, nasce Tizen. Contemporaneamente, Samsung
era alla ricerca di un nuovo sistema operativo per i propri prodotti, con il principale obiettivo
di diminuire la propria dipendenza da Android. Samsung si unı̀ al progetto, portando con sé
soluzioni ed esperienze acquisite con LiMo e Bada, due sistemi operativi precedenti.
Nel Gennaio 2012 nasce la Tizen Association42 a cui aderiscono produttori di dispositivi (OEM),
operatori telefonici, aziende di videogiochi e sviluppatori di applicazioni. Rappresenta un punto
di incontro per le aziende, un’occasione per poter prendere parte alle decisioni sul futuro della
piattaforma. Attualmente lo sviluppo del software è principalmente diretto da Samsung e Intel.
41
42
https://download.tizen.org/misc/media/
http://www.tizenassociation.org
52
La versione 1.0 di Tizen, Larkspur, viene rilasciata nell’Aprile del 2012. In Figura 15 viene
presentata un’anteprima della schermata di home della nuova versione 3.0, attualmente ancora
in fase di sviluppo.
4.2.3
Le architetture supportate
Attualmente sono supportate le architetture ARM ed Intel x86, sia 32 bit che 64 bit. Quest’ultima solo dalla versione 3.0 di Tizen.
4.2.4
Le applicazioni
Il package è l’entità di installazione in Tizen ed è un contenitore di applicazioni. Viene identificato in modo univoco tramite il PackageId. Ciascuna applicazione ha associato un identificativo
globalmente univoco, l’AppId ed un AppName. Tutte le applicazioni del pacchetto condividono
le risorse ed i privilegi [Il sistema dei privilegi 4.5.7] definiti a livello di package.
Dalla versione 2.0, Tizen supporta le applicazioni Native e Web.
• Native, scritte in C e C++, il linguaggio nativo della piattaforma. Ottimo per le performance e per il limitato consumo di memoria, inoltre vi è un ampia disponibilità di librerie
esistenti.
• Web, scritte in HTML, CSS e Javascript, i linguaggi del Web. Lo sviluppo è semplice, la
compatibilità è massima. Possono anche essere installate ed eseguite quando il dispositivo
è offline, ma non supportano l’esecuzione in background.
Dalla versione 3.0, Tizen aggiunge il supporto per le applicazioni Ibride [56]. Combinano la
semplicità dell’applicazione web con la potenza di calcolo di uno o più servizi scritti in linguaggio
nativo. Permettono un rapido sviluppo dell’interfaccia, tramite HTML5 e CSS3, ed un efficace
processamento dei dati in background grazie alla vasta disponibilità di librerie native.
Il packaging delle applicazioni Web segue le specifiche W3C43 :
• Il formato del file è un archivio ZIP.
• L’estensione del file è .wgt.
• MIME type: application/widget.
Il packaging delle applicazioni Native ed Ibride segue invece le seguenti specifiche:
• Il formato del file è un archivio ZIP.
• L’estensione del file è .tpk per le Native, .wgt per quelle Ibride.
• MIME type: application/x-tizen.package-archive.
Dalla versione 3.0, Tizen diventa un sistema operativo multi utente [57]: nonostante il sistema
possa essere utilizzato da un solo utente alla volta, più utenti possono essere registrati, ciascuno
con i propri dati e le proprie applicazioni.
43
World Wide Web Consortium (W3C)
53
4.2.5
Strumenti di sviluppo
Esistono versioni specifiche del Software Development Kit (SDK) per i profili Mobile, Wearable
e In-Vehicle Infotainment (IVI). Viene fornito un IDE (Eclipse), gli strumenti di compilazione
(toolchain) ed un emulatore basato su QEMU.
Per la connessione con il dispositivo, Tizen utilizza Smart Development Bridge (SDB) [58],
un tool da linea di comando che agisce da intermediario tra il dispositivo o emulatore e lo
strumento di debug. Permette eseguire una shell Unix da remoto, la sincronizzazione dei file e
la gestione dei log [59].
4.3
Architettura
Figura 16: Architettura del sistema operativo Tizen.44
L’architettura di Tizen, mostrata in Figura 16, è costituita da 4 componenti chiave: il Kernel,
il Core, il Framework Web ed il Framework Nativo.
4.3.1
Kernel
Dalla versione 2.0, Tizen adotta il Kernel di Linux 3.0. Contiene anche i driver per l’hardware
del dispositivo.
4.3.2
Core
Contiene l’implementazione dei servizi chiave, utilizzati sia dal Framework Web che da quello
Nativo.
Al suo interno si possono identificare i seguenti sotto-componenti [54] [60]:
44
Sorgente immagine: http://www.slideshare.net/seojuyung/fa-linux-tizenfinalpresent
54
• Application Framework: fornisce la gestione delle applicazioni. All’avvio del dispositivo,
si occupa di eseguire i servizi pre-definiti, come l’applicazione di chiamata. Gestisce la
notifica di eventi di base, come il livello di batteria basso, cambiamenti nell’orientamento
dello schermo e le notifiche push.
• Base: contiene le librerie di sistema di Linux. Include il supporto per il database e per il
parsing XML.
• Connettività: fornisce tutte le funzionalità legate alla comunicazione su rete, come 3G,
Wi-Fi, Bluetooth, HTTP e NFC (Near Field Communication). Il servizio di connettività
è basato sull’utilizzo del demone ConnMan45 , sviluppato da Intel.
• Grafica ed UI: gestisce lo stack dell’interfaccia grafica. Comprende EFL (Enlightenment
Foundation Libraries), un sistema di gestione delle finestre basato su X11, la gestione
degli input e OpenGL ES.
• Localizzazione: fornisce i servizi di localizzazione (LBS - Location Based Services). È
basata su GeoClue46 , un servizio che fornisce informazioni di localizzazione provenienti da
differenti sorgenti, come GPS, WPS (Wi-Fi Positioning System), ID della cella telefonica
e sensori. Permette inoltre di avere informazioni sui satelliti e lo stato del GPS.
• Messaggistica: fornisce i servizi di SMS, MMS, Email ed Instant Messaging.
• Multimedia: supporto per la visualizzazione di immagini e per la riproduzione video ed
audio.
• PIM (Personal Information Management): gestione dei dati dell’utente, come calendario
e lista dei contatti.
• Sicurezza: Sandboxing, controllo degli accessi, gestione dei certificati. Contiene i servizi
server di Smack, Cynara e Content Security Framework.
• System: gestisce diversi aspetti del dispositivo e di sistema: è un’interfaccia per l’accesso ai sensori, al display ed alla vibrazione. Gestisce il consumo energetico. Monitora gli eventi sul dispositivo, come USB, MMC, alimentatore e jack audio. Si occupa
dell’aggiornamento del sistema. Infine, fornisce le funzionalità di sveglia e ora.
• Telefonia: fornisce le funzionalità di comunicazione con il modem del dispositivo. Implementa i servizi di chiamata, messaggi, trasferimenti dati a pacchetto e informazioni di
rete per UMTS e CDMA.
• Web: contiene l’implementazione delle Web API di Tizen, ottimizzate per il basso consumo del dispositivo. Include il Web Runtime, per l’esecuzione delle applicazioni Web.
4.3.3
Framework Nativo
Viene rilasciato nella versione 2.0 di Tizen. Si occupa dell’installazione, disinstallazione e
aggiornamenti dei pacchetti applicativi [61]. Gestisce il ciclo di vita delle applicazioni e fornisce
un’interfaccia per la gestione degli eventi di sistema. Permette lo sviluppo di applicazioni native
e di servizi in C++, fornendo l’accesso ad oltre 10000 API. Include il supporto per le librerie
R ES, Open AL,
R Open
standard ed open source, come glibc, libstdc++, libxml2, Open GL
R
MP.
45
46
https://01.org/connman
http://freedesktop.org/wiki/Software/GeoClue/
55
4.3.4
Framework Web
Permette di eseguire le applicazioni che usano lo standard HTML5. Fornisce accesso a tutte
le API definite dal consorzio W3C: video, audio, touch, 2D canvas, WebGL, CSS3, geolocalizzazione, vibrazione, web socket, e web worker. Inoltre le Web Device API di Tizen estendono
l’accesso ai servizi di bluetooth, NFC, sveglia e messaggistica.
4.3.5
Web Runtime
Uno dei punti di forza di Tizen, è il supporto per le applicazioni Web. In tal senso, il Web
Runtime è uno dei componenti di maggiore interesse nell’architettura del sistema operativo.
Il Web Runtime (WRT) è il gestore del ciclo di vita di un’applicazione web. È responsabile
della loro installazione, disinstallazione ed esecuzione [62].
Il suo ruolo, per quanto simile a quello di un browser web, differisce nell’interfaccia grafica per
l’assenza dei controlli di navigazione e per l’accesso all’hardware sottostante tramite le Web
API. Gestisce la creazione e la distruzione dei processi relativi alle app anche in contemporanea
[63].
Fino a Tizen 2.x, il web runtime era basato su WebKit. Nel Settembre 2013, inizia il progetto
Crosswalk [64], per lo sviluppo di una nuova versione basata su Blink, il nuovo motore di rendering di Google. Presentato nel 2014, è stato inserito nella versione di Tizen 3.0. Attualmente
ne viene rilasciata anche una versione per Android.
La creazione di un nuovo Web Runtime è stata fortemente incentivato da Intel, che desiderava
uno sviluppo più aperto, senza “mailing list private”. Inoltre si voleva diminuire la differenza
di prestazioni tra le applicazioni native e Web.
Crosswalk è basato principalmente su Blink, ma eredita anche altri progetti, tra cui Chromium,
FFmpeg, Skia (per le librerie grafiche), V8 (il motore JavaScript) e la libreria Android Cordova.
Vi sono poi alcuni moduli sviluppati specificatamente per Tizen, come il parser del file di
Manifest [Il file Manifest 4.5.7], il runtime mode ed il Security Framework, l’implementazione
delle API W3C SysApps, oltre ad un framework per l’estensione di JavaScript.
Tutte le applicazioni Web in esecuzione condividono lo stesso processo Web Runtime.
4.4
Modello di sicurezza del sistema operativo
La progettazione di una soluzione di sicurezza per il sistema operativo Tizen, ha richiesto
la definizione di un modello definito sulla base delle minacce offerte dal panorama mobile
negli ultimi anni. In Figura 17 viene riportato uno schema riassuntivo. Le principali sfide di
sicurezza sono state identificate [65] nella diffusione di applicazioni malevoli, creazione di Store
non autorizzati, perdita di dati sensibili, meccanismi volti ad ingannare l’utente, nell’utente
stesso ed in attacchi da remoto.
A seguito è stato definito un sistema di livelli di fiducia: il kernel è trusted, ma il secure boot è
specifico del produttore del dispositivo. Il livello di fiducia di un’applicazione è legato a quello
associato allo sviluppatore. L’utente, nonostante sia il possessore del dispositivo, non è fidato.
Ugualmente non lo è lo sviluppatore.
Gli obiettivi di sicurezza sono stati dunque identificati nella protezione degli utenti, delle
applicazioni e del sistema [66].
47
Sorgente immagine: https://wiki.tizen.org/wiki/File:Threat.png
56
Figura 17: Il modello delle minacce.47
4.4.1
L’utente
Il sistema operativo mira a proteggere la privacy dell’utente.
L’utente ha pieni privilegi sull’interfaccia grafica, il Touch, la tastiera ed i tasti del dispositivo.
Non ha privilegi di amministratore e non può innalzarli. Non può modificare il file system,
né può mandare segnali ai servizi di sistema, ma può comunque invocare azioni privilegiate
per mezzo di applicazioni con sufficienti privilegi. In ultimo, è autorizzato ad installare le sole
applicazioni che siano state firmate da una Trusted Certificate Chain.
4.4.2
Le applicazioni
Figura 18: Modello di sicurezza del ciclo di vita delle applicazioni.48
Proteggere le applicazioni significa proteggere il processo, il codice eseguibile, i dati, le connessioni di rete e le informazioni di run-time.
Le applicazioni possono accedere all’interfaccia grafica ed ottenere l’input dell’utente. Non
hanno privilegi di amministratore. L’accesso in scrittura è garantito solo alle proprie directory.
48
Sorgente
immagine:
Security Lifecycle.png
https://wiki.tizen.org/w/images/thumb/0/0a/Security Lifecycle.png/600px-
57
L’utilizzo delle API, sensibili per la sicurezza dell’utente, è sottoposto a restrizione. L’accesso
ai dati di altre applicazioni non è consentito.
Nell’elaborazione di un modello di sicurezza per Tizen, Figura 18, viene anche definito anche il
modello del ciclo di vita sicuro delle applicazioni:
• Al termine della fase di sviluppo, l’applicazione deve essere firmata dallo sviluppatore per
i controlli di autenticità ed integrità.
• Inviata allo Store, l’applicazione viene sottoposta a controllo di validazione ed in caso di
successo, viene firmata dal distributore a conferma dell’ammissione al negozio virtuale.
• In fase di installazione è sottoposta a controllo anti-virus: il sistema operativo offre
un’interfaccia per controllare che il pacchetto applicativo non sia malevole.
• Durante la fase di esecuzione, ciascuna applicazione è confinata (Sandboxing) ed è sottoposta a controllo degli accessi.
4.4.3
Il sistema
La soluzione di sicurezza adottata deve proteggere il sistema: i servizi, le librerie condivise, i
database, il kernel, il boot loader ed i driver hardware.
I demoni di sistema sono eseguiti in un ambiente protetto e ricevono i minori privilegi possibili
(sul principio least privilege). L’accesso alle connessioni di rete è ristretto ed è garantito solo ai
componenti strettamente autorizzati. L’utente root è proprietario della maggior parte dei file
di sistema, accessibili unicamente in sola lettura dagli altri utenti. Per il controllo degli accessi,
si fa uso di una combinazione di tecniche derivanti dai modelli Discretionary Access Control
[Appendice 6.5.1] e Mandatory Access Control [Appendice 6.5.2].
4.4.4
I principali componenti
Di seguito sono elencati i principali componenti di sistema che si occupano di implementare la
soluzione di sicurezza in Tizen.
• Smack, Cynara e DAC : i tre pilastri della sicurezza in Tizen.
• Il sistema dei privilegi: per limitare limitare l’accesso delle applicazioni a componenti
“privacy-sensitive”.
• Vasum: un Environment Separation Mechanism.
• Tizen Store: il negozio virtuale per la distribuzione di applicazioni precedentemente
sottoposte a processo di revisione.
• Tizen Key Manager : un deposito sicuro, protetto da una password, per chiavi, certificati
e dati sensibili.
• Content Security and Reputation Framework : per la ricerca di malware e la classificazione
delle pagine Web.
• Tecniche di mitigazione delle vulnerabilità come ALSR e DEP.
58
• Protezione dell’accesso: una collezione di API per l’implementazione del blocco del dispositivo da accessi indesiderati.
Ciascuno degli elementi precedentemente elencati verrà trattato nelle successive sezioni dell’analisi del sistema operativo.
4.5
Tecniche di confinamento delle applicazioni
Il sistema operativo Tizen impiega delle tecniche di confinamento per eseguire le applicazioni in
un ambiente ristretto, in cui politiche dettagliate limitano l’accesso a risorse ed a componenti
di sistema.
Tizen 2.x L’isolamento delle applicazioni viene realizzato tramite l’utilizzo congiunto di
Smack, un’implementazione del modello MAC [Appendice 6.5.2], e dell’assegnazione di permessi di accesso al file system, specifici per utenti e gruppi. Quest’ultima è una soluzione di
sicurezza classica in Unix ed è un’implementazione del modello DAC [Appendice 6.5.1].
Smack, il principale componente di sicurezza, viene analizzato nelle sezioni 4.5.1 e 4.5.2, mentre
l’utilizzo degli UserID e GroupID in 4.5.3.
Tizen 3.0 La struttura utilizzata per il confinamento delle applicazioni viene modificata, nel
tentativo di alleggerire il ruolo di Smack all’interno del sistema operativo. Viene introdotto il
nuovo modello The three domain model ed un nuovo componente di sistema, Cynara, un policy
checker per il controllo degli accessi centralizzato. Le motivazioni di tale scelta e dettagli sui
componenti sono trattati nelle sezioni 4.5.4 e 4.5.5.
Conclude la prima parte 4.5.6 in cui vengono esposte critiche riguardo alle soluzioni adottate.
In 4.5.7 e 4.5.8 vengono introdotti il sistema dei privilegi e la firma dei pacchetti applicativi. A
seguire, in 4.5.9 e 4.5.10 si applicano tutti i concetti analizzati in una descrizione sull’installazione ed esecuzione delle applicazioni. In ultimo una descrizione di Vasum 4.5.11, un Environment
Separation Mechanism.
4.5.1
Smack - Simplified Mandatory Access Control Kernel
Introduzione Smack è un Linux Security Module (LSM) [24] che implementa il modello
Mandatory Access Control (MAC). È stato proposto e sviluppato da Casey Schaufler.
SELinux [27], la più nota implementazione del modello MAC, fornisce una soluzione di sicurezza
completa per Linux, ma appare complesso [67]. L’approccio di Smack è più semplice ed è rivolto
a risolvere problemi di sicurezza più piccoli, richiedendo minore configurazione ed un supporto
applicativo limitato. Smack è utile nelle implementazione di Sandboxing su Mobile per limitare
l’accesso di un utente e di alcuni processi alle risorse. In ogni caso non è da considerare general
purpose come SELinux. Smack è disponibile nel kernel Linux dalla versione 2.6.25.
Il controllo dell’accesso di Smack si fonda sull’utilizzo di etichette [68], semplici stringhe di
caratteri. Ogni soggetto, l’entità che vuole accedere ad una risorsa, ed oggetto, la risorsa,
ricevono un’etichetta. Di base un soggetto può accedere ad un oggetto solo se le due etichette
sono uguali, utilizzando un confronto case sensitive. È comunque possibile definire delle regole
accessorie per permettere diverse combinazioni.
49
Sorgente immagine: https://wiki.tizen.org/wiki/File:Smack-entire-flow-diagram.png
59
Figura 19: Schema di funzionamento di Smack.49
In Tizen i soggetti sono le applicazioni Web e native50 , gli oggetti, i servizi e le risorse (come
Wi-Fi, Bluetooth, 3G, GPS ed accelerometro), file, cartelle e socket.
L’idea alla base di Smack è estremamente semplice, ma il meccanismo di controllo degli accessi
tende a diventare complesso all’aumentare del numero di applicazioni e di risorse da controllare.
Un numero molto alto di etichette è difficile da gestire, ma soprattutto può portare ad errori
ed inconsistenze e ad un aumento dei tempi di risposta.
Smack in pillole
• Soggetto: qualsiasi processo in esecuzione.
• Oggetto: file, risorse, socket, processi.
• Cinque tipi di accesso: lettura (r), scrittura (w), esecuzione (e), lock (l), transmute (t).
• Ad ogni soggetto ed oggetto viene assegnata un’etichetta.
• L’etichetta è una stringa di testo ed il suo valore non ha significato.
• Gli oggetti ereditano l’etichetta dai soggetti che li crea.
• La regola di accesso di base: le etichette devono coincidere (confronto case sensitive).
• Ulteriori regole di accesso possono essere specificate nella forma di tupla:
– soggetto - oggetto - accesso.
• Esistono tre etichette speciali in Tizen:
–
floor: associata ad un oggetto, permette sempre la lettura.
– * star: associata ad un oggetto, permette sempre accesso in lettura e scrittura.
– ˆ hat: associata ad un soggetto, permette la lettura di qualsiasi oggetto.
50
Più in generale tutti i processi in esecuzione.
60
Le etichette L’etichetta, label, è una stringa ASCII lunga fino a 23 caratteri. Il nome
associato dell’etichetta è importante per aumentare la leggibilità delle regole.
Le etichette assegnate alle risorse, gli oggetti, sono confrontate con quelle del processo che
tenta di accedervi, il soggetto. L’impostazione predefinita prevede che l’accesso sia consentito
soltanto se le due etichette sono uguali. Un amministratore, però, può aggiungere delle regole
sotto forma di tupla soggetto - oggetto - diritti di accesso.
Smack non supporta le wildcard o espressioni regolari e non vale la proprietà transitiva delle
regole. Ad esempio: se a può accedere a b e b può accedere a c, questo non vuol dire che a
possa accedere a c. Affinché questo possa valere, deve essere inserita una nuova regola specifica.
Esiste inoltre un insieme di etichette Smack riservate (floor , hat ˆ, star *) alle quali si applicano
regole differenti da quelle di base. Questo permette all’amministratore di limitare il numero di
regole da creare per utenti e processi.
L’implementazione Smack utilizza gli extended attributes del file system51 , per salvare
l’etichetta associata a ciascun file.
Per la configurazione, Smack usa la stessa tecnica di SELinux, definendo un file system: smackfs.
Montato come /sys/fs/smackfs, fornisce diversi file che possono essere letti o scritti per la
configurazione. Le regole Smack vengono salvate nel database Smack Policy 52 e caricate in
memoria kernel al boot time [69]. Per effettuare delle modifiche, basta aggiungere una nuova
tupla: soggetto - oggetto - regola di accesso.
Tool Sono disponibili delle versioni modificate di alcuni tool Unix per la gestione delle
etichette [70] [71]:
• attr: per impostare le etichette a file e cartelle.
• chsmack: per visualizzare e settare le etichette associate ad un file.
• ls -Z: visualizza le etichette associate ai file.
• sshd: associa etichette agli utenti. Rimangono settate fino al logout.
• id e id -Z: per mostrare l’etichetta del processo corrente.
• ps -Z: per visualizzare informazioni sui processi, incluse le etichette Smack.
Ad esempio: per impostare l’etichetta riservata * a /dev/null si usa il seguente comando:
a t t r −S −s SMACK64 −V ’ ∗ ’ / dev / n u l l
Esempio Di seguito un esempio in cui si applicano delle regole Smack accessorie per replicare
i livelli di classificazione standard dei documenti governativi: Unclass per non classificato, C
per classificato, S per segreto e TS per top secret.
Di seguito con poche regole è possibile stabilire la tradizionale gerarchia di accesso.
51
52
Smack fa uso dell’attributo security.SMACK64 per i file e di security.SMACK64EXEC per gli eseguibili.
/sys/fs/smackfs/load
61
C
S
S
TS
TS
TS
Unclass
C
Unclass
S
C
Unclass
rx
rx
rx
rx
rx
rx
Per default, Unclass sarà solo in grado di accedere ai dati con la stessa etichetta, mentre per
le regole definite di sopra, TS può accedere ai file etichettati S, C, Unclassed files.
4.5.2
Smack in Tizen
Livelli gerarchici di Smack ed utilizzo L’utilizzo della combinazione di etichette e regole
Smack permette di definire dei livelli gerarchici di accesso [72], a ciascuno dei quali è associato
uno specifico caso d’uso. Nella tabella che segue, a livello crescente, corrisponde un accesso più
ristretto.
Livello
1
2
3
4
Utilizzo
Accesso illimitato
Condivisione file
Sandboxing
Controllo accessi
Etichetta soggetto
qualsiasi
qualsiasi
specifica
specifica
Etichetta oggetto
*
Accesso
rwx
rx
la stessa del soggetto rwx
specifica
basato su regole
Il primo livello viene impiegato per fornire accesso illimitato a quelle risorse utili a tutti gli
applicativi. Questo permette un grande risparmio di regole Smack, che altrimenti sarebbero
dovute essere definite per ogni soggetto Smack (applicazione). Ad esempio, i direttori /dev/null
e /dev/zero ricevono l’etichetta star (*), dunque hanno accesso illimitato.
Il secondo livello viene utilizzato per la condivisione dei file tra le applicazioni. Associare
alle cartelle condivise l’etichetta floor ( ), permette a qualsiasi processo l’accesso in lettura ed
esecuzione ai dati contenuti. Inoltre, le cartelle /lib, /bin, /usr/lib, /etc, /dev ricevono tutte
l’etichetta floor (“ ”).
Il terzo livello gerarchico viene impiegato per l’implementazione del Sandboxing delle applicazioni: se le etichette del soggetto e dell’oggetto sono le stesse, l’accesso dell’applicazione ai
propri dati viene gestito senza la necessità di definire altre, più specifiche, regole Smack.
L’ultimo e più restrittivo livello, il quarto, viene utilizzato per la gestione dei permessi associati
alle applicazioni. In Tizen 2.x, al momento dell’installazione [4.5.9] viene creato un nuovo
dominio per il pacchetto applicativo e vengono definite delle regole per limitare l’accesso alle
sole risorse consentite.
4.5.3
UserID e GroupID
Tizen 2.x Non è un sistema operativo multi utente, ma l’utilizzo degli UserID e GroupID
e l’assegnazione dei permessi di accesso al file system rappresenta un’importante componente
nel confinamento delle applicazioni [73]. Questa soluzione di sicurezza, classica di Unix, è
un’implementazione del modello DAC [Appendice 6.5.1].
In Tizen 2.x esistono 3 utenti: root (UID 0), app (UID 5000) e developer (UID 5100). Tutte le
applicazioni sono eseguite dall’utente app (userID 5000), nessuna dall’utente root (user ID 0).
La shell di sdbd 53 viene invece eseguita con user ID 5100.
53
Demone di sistema dello Smart Development Bridge (SDB), un tool di debug.
62
Nella tabella 4.5.3 sono mostrate alcune impostazione per l’accesso a file e cartelle:
Descrizione
Configurazione di base per tutti i file dell’utente root
File eseguibili e cartelle dell’utente root
File del Framework estremamente importanti
Cartella shared nella home dell’applicazione54 User: root
Cartelle data e tmp nella home dell’applicazione55 User: app
File globalmente accessibili, come /dev/zero, /dev/null e /tmp
Permessi
rw-r--r-- (644)
rwxr-xr-x (755)
rw------- (600)
rwxr-xr-x (755)
rwx------ (700)
rw-rw-rw (666)
Tabella 1: Alcuni esempi di permessi per le cartelle degli utenti root e app.
Tizen 3.0 Il sistema operativo diventa multiutente [74]. Certamente l’utilizzo degli UserID
e GroupID cambia, ma non sono disponibili informazioni a riguardo.
4.5.4
The three domain model
Per poter comprendere le motivazioni alla base del cambiamento attuato da Tizen 3.0 nel
modello di confinamento delle applicazioni, vengono qui anticipati alcuni concetti sui privilegi
delle applicazioni, che verranno poi spiegati in dettaglio nella successiva sezione 4.5.7: “Il
sistema dei privilegi”.
In Tizen, i privilegi delle applicazioni vengono specificati facendo riferimento a servizi astratti,
come “telefonia”, piuttosto che indicando dettagliatamente le risorse di sistema effettivamente
usate per implementare la soluzione. Se da un lato questa scelta facilita la definizione dei
permessi nello sviluppo delle applicazioni, dall’altro rende complicato il modo in cui i servizi
astratti vengono mappati nei diversi componenti di sistema utilizzati.
Tizen 2.x La funzione di mappatura è affidata interamente a Smack, utilizzando delle politiche di controllo degli accessi molto dettagliate: ogni applicazione ha associato un dominio
ed un’etichetta. Ad ogni nuova installazione, per tutte le risorse ed i componenti a cui l’applicazione ha il privilegio di avere accesso, è necessario definire delle specifiche regole Smack
(ulteriori dettagli in 4.5.9). Il problema è il numero di regole: 41000 in Tizen 2.2.1 [75], cosı̀
vasto da risultare ingestibile. Ulteriormente, non vi è distinzione tra le etichette di sistema e
quelle utente e viene impiegato un algoritmo di ricerca lineare, lento.
Tizen 3.0 Viene introdotto un nuovo modello di controllo degli accessi compatto, the three
domain model : tre domini, tre gruppi di etichette ed alcune regole già definite [76].
In Tizen esistono fondamentalmente due tipi di dati:
• Dati utente di proprietà dell’utente finale.
• Dati di sistema che non possono essere cambiati dall’utente finale.
I processi utente devono avere accesso ai dati del sistema e comunicare con i processi di sistema.
Una soluzione pratica è quella di dividere i dati di sistema in una parte accessibile in lettura
da chiunque ed in una che comunica con il processo utente. Il risultato sono i tre domini:
63
User : per i processi ed i dati utente.
System: per i processi di sistema ed i loro dati privati.
Floor : per i dati di sistema pubblici.
L’accesso intra-dominio è libero, ma quello cross-dominio è ristretto e strettamente controllato.
Ad ogni dominio è associato un gruppo di etichette Smack. Le principali sono:
• User e User::App::$app id, associate al dominio User.
• System, associata al dominio System.
•
floor, * star e ˆ hat, associate al dominio Floor, mantengono lo stesso significato spiegato
in 4.5.1.
A differenza della versione precedente, dove un nuovo dominio veniva creato ad ogni installazione, in Tizen 3.0 i tre domini di sicurezza sono creati preventivamente. Da notare che ogni
applicazione installata, riceve ancora una propria etichetta, ma il dominio di appartenenza
rimane quello User.
L’adozione del “Three Domains Model” ha permesso di rendere le regole Smack più chiare e
più semplici da gestire. Inoltre, ha consentito di velocizzare il sistema, sia al tempo di boot
(nella fase di loading delle regole), sia a run-time (nel processamento delle regole).
Figura 20: I pilastri del modello della sicurezza di Tizen 3.0.56
Nonostante questa soluzione semplifichi il controllo degli accessi, permettendo di ridurre il numero di etichette, la bassa granularità dei tre domini, non fornisce un controllo dell’accesso alle
risorse sufficientemente dettagliato per garantire la protezione del sistema e di ciascuna applicazione. È stato quindi necessario introdurre un nuovo componente, Cynara, con la funzione
di policy checker : controllare i privilegi delle applicazioni che tentano di accedere alle risorse
ed alle API “privacy-sensitive”.
In Tizen, l’utilizzo congiunto di UserId e GroupID (DAC), Smack e Cynara da origine ai “I tre
pilastri della sicurezza di Tizen 3.0”, Firgura 20.
4.5.5
Cynara
Cynara è un policy checker e viene introdotto nella versione di Tizen 3.0 [77].
56
57
Sorgente immagine: https://wiki.tizen.org/wiki/File:SmackCynaraDAC 443 418.png
Sorgente immagine: https://wiki.tizen.org/wiki/File:CynaraInputData 842 504.png
64
Figura 21: Le sorgenti che popolano il database di Cynara.57
I servizi di sistema necessitano di un meccanismo di controllo per verificare che chi vi accede
abbia privilegi sufficienti.58 In Tizen 2.x questa funzione veniva offerta da un set molto dettagliato di regole Smack. La semplificazione introdotta dal “Three domain model” [4.5.4] rende
necessario un nuovo componente che memorizzi i privilegi associati a ciascuna applicazione ed
esponga una semplice chiamata API per il controllo delle policy di accesso.
Cynara fornisce un database per memorizzare i permessi associati ad un’applicazione, mantiene
il complicato mapping tra i “privilegi astratti” e le risorse di sistema ed espone una libreria
client leggera per rendere il controllo degli accessi semplice [78].
Cynara in dettaglio In riferimento alla Figura 21, il database di Cyanara viene popolato
utilizzando diverse sorgenti:
• Le regole built-in definite dall’OEM.
• Le regole imposte dall’amministratore di sistema.
• Utilizzando il file Manifest dell’applicazione durante la fase di installazione [ulteriori
dettagli in 4.5.9].
• Utilizzando il Privacy Manager per gestire le scelte dell’utente nella concessione dei
permessi alle applicazioni [ulteriori dettagli in 4.5.7].
Nel database, ogni applicazione univocamente identificata da un’etichetta Smack, ha associata
un lista di privilegi. I servizi di sistema fanno richiesta a Cynara per il controllo dell’accesso
fornendo una tripletta: utente, applicazione e permesso.59 Cynara è ottimizzato per minimizzare i tempi di risposta, tramite cache dei risultati. Il tempo medio per un controllo di accesso
è inferiore ai 10 ms, contro i 30ms medi delle implementazioni alternative [79].
In figura 22, viene mostrato un esempio di utilizzo di Cynara. Quando un’applicazione in
esecuzione richiede l’accesso ad un componente di sistema, ad esempio il GPS, il componente
58
Vengono qui anticipati alcuni concetti sui privilegi delle applicazioni, che verranno poi spiegati in dettaglio
nella successiva sezione 4.5.7: “Il sistema dei privilegi”.
59
Cynara è pensato per supportare un sistema operativo multi-utente.
60
Sorgente immagine:
https://wiki.tizen.org/w/images/thumb/7/7e/CynaraSchema ver 1 0.png/750pxCynaraSchema ver 1 0.png
65
Figura 22: Controllo degli accessi in Cynara.60
manda una richiesta a Cynara61 . Quest’ultimo risponde con un messaggio di ALLOW o DENY,
in base alla presenza della combinazione etichetta smack e privilegi consentiti nel database
delle policy. Per un controllo più fine, nel processo decisionale può intervenire un un “agent
esterno”, implementato nella forma di plug-in. Ad esempio, si potrebbe usare un popup, in
cui l’utente può scegliere se consentire l’accesso ad una determinata risorsa. In ogni caso l’idea
alla base di Cynara è quella di offrire una risposta precisa: permesso o non permesso. Se non
viene consentito l’accesso ad una risorsa, o ad un’API privilegiata, a livello applicativo viene
generata una SecurityError Exception.
4.5.6
Commenti sul modello del controllo degli accessi in Tizen
Di seguito vengono riportate alcune critiche sul modello del controllo degli accessi in Tizen,
prendendo riferimento da quanto emerso nella presentazione ufficiale [78].
• Tizen 2.0 utilizza politiche di sicurezza del sistema scritte come un insieme di regole
Smack, nel tentativo di isolare le singole applicazioni vengono creati dei domini separati
ad ogni nuova installazione. La stessa soluzione viene adottata sia in SELinux che in
AppArmor, per questo Smack viene ritenuto essere, in parte, la reinvenzione di una
soluzione esistente.
• Nella presentazione di Cynara [78], Tomasz Świerczek ha annunciato che le performance
di Cynara sono migliori rispetto ad altre soluzioni esistenti, come ad esempio Polkit.
Quest’ultimo, in particolare, viene indicato come caratterizzato da scelte architetturali
carenti per l’utilizzo di Json e XML per lo storage e l’assenza di cache. Questi sembrano
più problemi implementativi, che architetturali. In ogni caso, una soluzione studiata
appositamente per un sistema operativo mobile, come Cynara, può avere alcuni vantaggi,
anche in termini di velocità.
• Cynara permette anche meccanismi aggiuntivi per il controllo delle policy, tra cui popup
da visualizzare all’utente. È dimostrato che demandare all’utente le decisioni di sicurezza,
61
tramite l’API cynara check()
66
Figura 23: Controllo dei privilegi nel menù impostazioni.62
non è la soluzione [80]: per troppo a lungo gli utenti sono stati abituati a rispondere
automaticamente si ad ogni dialog di conferma.
Nonostante Smack presenti alcuni elementi in comune con le soluzioni esistenti, risulta essere
cosı̀ semplice, da rimanere molto interessante. Solo con il tempo si saprà se la verifica, i
permessi o le etichette di Smack possono essere falsificati da applicazioni malevoli. Con permessi
falsi, un’applicazioni potrebbe accedere ai demoni di servizio ed ottenere informazioni sensibili
senza il consenso dell’utente. Inoltre potrebbe avere accesso o modificare informazioni in altre
applicazioni. Il modello di sicurezza crollerebbe.
4.5.7
Il sistema dei privilegi
Tizen fornisce un controllo sull’accesso alle API ed ai servizi privacy-sensitive il cui utilizzo può
compromettere la privacy dell’utente e la stabilità del sistema.
Alcuni servizi sono sensibili per la sicurezza dell’utente e del sistema e non dovrebbero essere
disponibili per tutte le applicazioni. Per esempio, leggere un SMS è un’operazione sensibile:
i messaggi in arrivo potrebbero contenere informazioni riservate e quelli in uscita potrebbero
comportare una spesa per l’utente [Introduzione 1.2.1]. Quindi alcune funzionalità non devono
essere disponibili per tutte le applicazioni, ma solo per quelle per cui l’utente ha approvato
durante l’installazione, o a run time, il loro utilizzo. Le applicazioni già installate dall’OEM,
sono invece considerate trusted dal sistema operativo.
La maggior parte dei privilegi sono legati all’utilizzo delle API corrispondenti. Altri, come
“privilege/internet” o “privilege/mediastorage”, sono puramente basati su una risorsa. Il livello
di privilegio associato alle API è definito nel file di configurazione delle Policy di Tizen. Membri
della Tizen Association, possono cambiarle in accordo con le loro necessità, nonostante sia
un’operazione molto rischiosa dal punto di vista della sicurezza del sistema operativo.
62
Sorgente immagine: https://developer.tizen.org/dev-guide/2.2.1/org.tizen.gettingstarted/html/tizen overview/exception
67
Le applicazioni dichiarano i permessi richiesti nel file di Manifest, ma quelli realmente concessi
dalla piattaforma Tizen, dipendono dalla tipologia di firma utilizzata. In fase di installazione, il
gestore dei pacchetti confronta la firma utilizzata dal distributore dell’applicazione, con quelle
disponibili nel sistema per i differenti livelli di privilegio [ulteriori dettagli in 4.5.8]. Il risultato
del confronto definisce il massimo livello di privilegi disponibile per l’applicazione installata ed
il relativo accesso alle API.
Nella versione 2.2.1[81] di Tizen è stato aggiunto il pannello Privacy Manager nel menù Settings.
Selezionando un applicazione è possibile, a posteriori, la modifica delle regole di accesso63 . In
Figura 23 è mostrata la schermata per l’applicazione TestApp. La modifica dei privilegi associati
ad un’applicazione ha conseguenze sul funzionamento dell’eseguibile: quando un’applicazione
tenta di utilizzare le API privacy-sensitive i cui privilegi di utilizzo sono stati bloccati nelle
impostazioni di privacy del dispositivo, viene generata un’eccezione64 nel codice. È importante
che in fase di sviluppo l’applicazione abbia gestito correttamente tali eccezioni. Le linee guida
di Tizen [82] consigliano di visualizzare un messaggio all’utente per spiegare il motivo per cui
l’azione è stata interrotta.
Il file Manifest Il Manifest è un file in formato XML. Viene utilizzato dalle applicazioni per
specificare i privilegi per le API, i servizi utilizzati ed altri parametri come l’Id dell’applicazione
e del package, l’icona e se abilitare la rotazione della schermata. Le applicazioni native ed
ibride utilizzano un file chiamato manifest.xml, mentre quelle Web, config.xml. Di seguito viene
riportato un esempio di Manifest per le applicazioni Web [83].
<?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8”?>
<w i d g e t xmlns=” h t t p : / /www. w3 . o r g / ns / w i d g e t s ” xmlns : t i z e n=” h t t p : / / t i z e n .
o r g / ns / w i d g e t s ” i d=” h t t p s : / / g i t h u b . com/01 o r g / webapps−annex ” v e r s i o n=
” 1 . 0 ” width=” 512 ” h e i g h t=” 300 ”>
<i c o n s r c=” annex−i c o n . png”/>
<c o n t e n t s r c=” i n d e x . html ”/>
<name>annex</name>
<t i z e n : a p p l i c a t i o n i d=” 33 CFo0eFJe . annex ”
package=” 33 CFo0eFJe” r e q u i r e d \ v e r s i o n=” 1 . 0 ”/>
<t i z e n : s e t t i n g s c r e e n −o r i e n t a t i o n=” p o r t r a i t ” contextmenu=” e n a b l e ”/>
</widget>
Gerarchia dei privilegi I privilegi sono organizzati su tre livelli gerarchici [84], sulla base
dei rischi di sicurezza associati al loro utilizzo.
• Public: è il livello minimo, garantito a tutte le applicazioni sviluppate con il SDK. È
aperto a tutti gli sviluppatori.
• Partner: accessibili solo dagli sviluppatori registrati come partner presso il Tizen Store.
• Platform: disponibili solo per gli sviluppatori che lavorano per il consorzio di Tizen.
Comprende le API utilizzate dal framework e dalla piattaforma Tizen.
63
La modifica dei privilegi tramite il Privacy Manager comporta, in Tizen 2.x, un aggiornamento dei database Privilege DB e Smack Policy (trattati in 4.5.9). A partire da Tizen 3.0, la modifica dei permessi di
un’applicazione viene gestita dal nuovo componente Security Manager.
64
SecurityError per le applicazioni Web, E USER NOT CONSENTED per quelle native.
68
Tipologia dei privilegi Esistono due tipi di privilegi: i nativi o core ed i web o wrt. I primi
sono associati alle applicazioni native, i secondi alle applicazioni web.
Di seguito alcuni esempi di privilegi nativi:
• calendar.read : l’applicazione può leggere gli eventi del calendario (livello public).
• appmanager.kill : l’applicazione può chiudere altre applicazioni (livello platform).
Un esempio di privilegi web:
• packagemanager.install : l’applicazione può installare o disinstallare pacchetti applicativi
(livello platform).
Una lista esaustiva dei privilegi è disponibile nella guida per gli sviluppatori di Tizen65
4.5.8
66
.
Firma delle applicazioni
In Tizen è richiesto che i pacchetti applicativi, per potere essere installati, siano firmati con la
firma dell’autore e del distributore [85].
La firma dell’autore è il meccanismo di verifica dell’appartenenza dell’applicazione allo
sviluppatore ed assicura l’integrità del pacchetto applicativo, cosı̀ come è stato inviato dallo
sviluppatore. Permette di creare una trusted-relationship tra un’applicazione ed una sua nuova
versione, fondamentale nel processo di aggiornamento. Inoltre consente di instaurare una trusted inter-application-communication, un meccanismo di comunicazione tra le sole applicazioni
firmate con la stessa chiave dello sviluppatore, all’interno dello stesso dispositivo. Il certificato
dello sviluppatore, può essere creato tramite il Tizen IDE.
La firma del distributore viene applicata dal distributore delle applicazioni, come il Tizen Store (trattato in 4.7), per certificare la provenienza e verificare l’integrità del pacchetto
applicativo, cosı̀ come è stato pubblicato sullo Store. Fornisce la garanzia che l’applicazione
abbia superato il processo di revisione e determina il massimo livello di privilegi concessi. Ad
esempio, se l’applicazione viene firmata con un certificato di livello pubblico, allora avrà accesso
ai soli privilegi di livello pubblico.
In fase di sviluppo delle applicazioni, è possibile creare una coppia di certificati temporanei per
ottenere il livello di privilegi partner e platform [86]. Tuttavia, a differenza dell’emulatore, per
effettuare il test su dispositivi reali è necessario che le “Opzioni per gli sviluppatori” siano state
abilitate nel dispositivo. Successivamente, in fase di distribuzione dell’applicazione, la firma
temporanea sarà sostituita da quella del reale canale di distribuzione, come ad esempio il Tizen
Store.
La firma delle applicazioni segue le specifiche W3C67 :
• L’algoritmo di firma raccomandato è RSA con SHA 256.
• La lunghezza raccomandata della chiave per RSA è di 4096 bit.
• Il metodo di digest raccomandato è SHA-256.
• Il formato di certificato raccomandato è X.509 versione 3 come specificato in [RFC5280].
65
https://www.tizen.org/privilege
https://wiki.tizen.org/wiki/Security/Tizen 2.X Privileges#Privilege Categorization
67
http://www.w3.org/TR/widgets-digsig/
66
69
4.5.9
Installazione delle applicazioni
Figura 24: Schema dei passaggi per l’installazione di un’applicazione.68
Di seguito vengono descritte le fasi di installazione di un’applicazione [85].
Tizen 2.x Si faccia riferimento alla Figura 24.69 .
1. Il gestore dei pacchetti, o Installer, effettua il controllo delle firme dello sviluppatore e del
distributore sul pacchetto applicativo.
2. Viene effettuato il parsing del file di Manifest, al fine di controllare che i privilegi richiesti
dall’applicazione siano compatibili con la tipologia di firma utilizzata dal distributore.
3. Si procede alla copia dei file eseguibili nella cartella bin nella home dell’applicazione70 .
Poiché l’Installer viene eseguito dall’utente root, di default tutti i file sono di proprietà di
root [73], ma in seguito lo UserId ed il GroupId dei direttori data e tmp sono settati ad app
[rif 4.5.3]. Infine l’installer setta l’etichetta Smack per tutti i file dell’applicazione uguale
all’ApplicationID (ad eccezione della cartella shared a cui viene associata l’etichetta floor ).
Per default, un’applicazione è quindi in grado di accedere a tutte le sue risorse.
4. I privilegi associati dall’applicazione vengono aggiunti al database dei privilegi (Privilege
DB ).
5. I privilegi dichiarati dall’applicazione sono convertiti in regole Smack sulla base di alcuni
template definiti in smack-privilege-config 71 [88].
6. Il database delle Smack policy viene aggiornato, con l’aggiunta delle nuove regole Smack
create al punto precedente.
68
Sorgente immagine: https://wiki.tizen.org/wiki/File:Access control architecture.png
Durante la fase di installazione, tutta la gestione dei privilegi avviene tramite l’utilizzo delle libprivilegecontrol API [87].
70
/opt/usr/apps/[APPLICATION ID]
71
Ciascun template ha estensione .smack e si trova in /usr/share/privilege-control.
69
70
Tizen 3.0 Al fine di diminuire il numero di nuove regole Smack create ad ogni nuova installazione, viene introdotto un nuovo componente: Cynara [rif 4.5.4 e 4.5.5]. Il processo di
installazione rimane simile, con la differenza dell’introduzione del Security Manager [89], un
demone di sistema privilegiato, incaricato di settare correttamente gli attributi di file e cartelle,
di assegnare le etichette Smack e di popolare il database di Cynara.
4.5.10
Esecuzione delle applicazioni
Figura 25: Schema dei passaggi per l’esecuzione di un’applicazione Nativa.72
Tizen 2.x Il launchpad daemon è il demone, eseguito dall’utente root, che interviene nella
creazione di un nuovo processo [90] ed è il processo padre di tutte le applicazioni nel sistema
operativo.
Di seguito le fasi necessarie per il lancio di un’applicazione Nativa, Figura 25:
• Il launchpad daemon crea un nuovo processo figlio, tramite la system call fork().
• UserId e GroupId del nuovo processo vengono impostati a 5000 (app) [4.5.3].
• Viene settata l’etichetta Smack corretta, utilizzando le libprivilege-control API [87].
• A seguito della chiamata alla system call exec(), inizia l’esecuzione dell’applicazione
richiesta.
• Durante l’esecuzione le applicazioni sono confinate tramite le tecniche descritte in 4.5.
Il caso di un’applicazione Web, si differenzia da quella nativa per alcune fasi iniziali aggiuntive.
In fase di installazione viene viene creato un soft link al Web Runtime73 , etichettato con la
72
73
Sorgente immagine: https://wiki.tizen.org/wiki/File:Libprivilege-control pig1.png
L’eseguibile di un’applicazione Web è un link simbolico a /usr/bin/wrt-client.
71
label Smack associata all’applicazione. Quando l’applicazione Web viene lanciata, Tizen esegue
il soft-link corrispondente, il Web Runtime inoltra la richiesta al wrt launchpad (una versione
specializzata del launchpad daemon). Le fasi seguenti sono identiche a quelle precedentemente
descritte.
Tizen 3.0 Durante la fase di lancio, il Security Manager [89] setta l’etichetta Smack ed il
GroupId (DAC) del nuovo processo creato, in modo tale da garantire al processo l’accesso ai
propri file. A run-time l’applicazione potrebbe richiedere l’accesso ad ad un servizio di sistema
o al file system. Nel primo caso l’etichetta Smack associata al processo applicativo viene usata
da Cynara per controllare se l’accesso possa essere garantito. Nel secondo, il filesystem utilizza
gli attributi UserId e GroupID e l’etichetta Smack per effettuare gli opportuni controlli.
4.5.11
Vasum
Figura 26: L’architettura di Vasum con due zone in esecuzione.74
Tizen implementa il meccanismo di Sandboxing delle applicazioni basandosi principalmente sui
modelli del controllo degli accessi MAC e DAC. Questa soluzione permette una separazione
a livello dell’applicazione, ma l’ambiente di esecuzione rimane unico. Vasum [91] è un Environment Separation Mechanism basato su Linux Containers/LXC (dettagli in Appendice 6.6),
che consente di avere su uno stesso device più ambienti di esecuzione separati, chiamati zones,
ciascuno dei quali esegue virtualmente una copia del sistema operativo Tizen. Il principale
beneficio offerto è quello di avere ambienti di esecuzione separati per il test di applicazioni malevoli, per lo sviluppo di applicazioni che necessitano di configurazioni specifiche e per limitare
le funzionalità di un dispositivo dato in dotazione. Attualmente Vasum è ancora in una fase
di sperimentazione e non è stato inserito nell’Open Build Service (OBS)75 , il servizio per la
raccolta dei pacchetti software di una release del sistema operativo.
Il modello logico di Vasum prevede l’esecuzione contemporanea di una versione nativa del
sistema operativo, host, e di alcune istanze virtualizzate, guest.
Tizen nativo si occupa di:
74
75
Sorgente immagine: https://wiki.tizen.org/wiki/File:VasumDiagram v1.png
https://build.tizen.org/project/show?project=Tizen%3AMobile
72
• Gestire le risorse hardware del dispositivo.
• Eseguire alcuni servizi critici che ha senso siano presenti in una sola istanza per ciascun
dispositivo, tra cui il server Vasum, descritto in seguito.
• Gestire il ciclo di vita e le risorse delle zone.
• Mediare nella comunicazione tra zone e ricevere da ciascuna le richieste per le operazioni
privilegiate, come l’avvicendamento della zona in foreground.
Tizen virtualizzato in una zona, è incaricato di:
• Installare ed eseguire le applicazioni di ciascuna zona.
• Eseguire i servizi di sistema necessari per ogni guest.
• Fornire lo storage per i dati e delle configurazioni di ciascuna zona.
• Fornire i meccanismi di condivisione intra-zona.
Installare le applicazioni nel guest, richiede che tutte le operazioni privilegiate, come settare le
etichette Smack, siano eseguite dall’Installer [rif 4.5.9], con il quale l’applicazione di installazione
specifica di una zona comunica su socket. L’Installation Service, rispetto alla versione standard
di Tizen, necessita di alcune modifiche per supportare la gestione delle zone in Vasum.
Dal punto di vista implementativo, figura 26, Vasum è costituito da una componente Server e
da una Client, di seguito analizzate.
Server Il server Vasum è un servizio systemd che implementa la maggioranza delle funzionalità logiche, di sopra descritte.
• Per motivi di sicurezza, viene eseguito da un utente non root.
• Espone un set di API utilizzabili sia dai servizi in esecuzione sull’host, che da quelli in
una zona.
• Si occupa di mantenere la comunicazione sia con i client, che con i bus rispettivi di ciascuna
zona e permette di contattare altri servizi in esecuzione sull’host, come Cynara[rif 4.5.5].
• Gestisce il ciclo di vita delle zone (start, stop e restart), l’avvicendamento di quella in
esecuzione e mantiene la configurazione di ciascuna. La decisione sullo scheduling delle
zone, può essere presa autonomamente, o essere richiesta esplicitamente da un servizio di
sistema, usando la chiamata ad un’API specifica o dall’utente, tramite il triplo click sul
bottone di home.
• Sfruttando le impostazioni dello scheduler ed i Cgroup di Linux, è in grado di dare priorità a servizi di sistema o ad alcune applicazioni critiche in esecuzione in una zona in
background e di congelare quelle delle altre zone.
• Fornisce un set di API per la comunicazione intra-zona, messaggi broadcast per la comunicazione tra zone e funzione di relaying per i client in ascolto.
73
Client Il client comunica con il server Vasum tramite alcune API.
• Permette a servizi ed alle applicazioni in esecuzione in una zona di ottenere il controllo,
anche se parziale, sul dispositivo.
• Consente ad un servizio, in esecuzione sull’host, di comunicare con le applicazioni all’interno di una zona.
• Include un meccanismo di notifica per l’utente, per informarlo nel caso in cui una zona in
background richieda la sua attenzione.
• Comprende un’applicazione grafica che consente la gestione delle zone da parte dell’utente:
creazione, distruzione ed impostazione dei privilegi.
4.6
Criticità progettuali ed implementative delle applicazioni
In questa sezione vengono trattate alcune tematiche che introducono delle potenziali debolezze
nelle applicazioni in Tizen.
In 4.6.1, viene presentata una soluzione proprietaria per la conversione delle applicazioni da
Android a Tizen. Se da un lato risulta essere molto attraente per l’aumento di interesse verso
la piattaforma, dall’altro non sono noti i risvolti di sicurezza.
Viene in seguito trattato l’utilizzo OpenGL nelle applicazioni Web, 4.6.2, un problema ipotizzato in [92], su cui l’autore del report ha voluto indagare più approfonditamente.
A concludere, 4.6.3, un’esposizione sul Cross Site Scripting nelle applicazioni Web. Un problema
già noto alla comunità Tizen [92], ma per cui non sono state sviluppate contromisure, né sembra
che ve ne siano in progetto.
4.6.1
Conversione automatica della applicazioni
In occasione della Tizen Developer Conference del 2013 [93], Infraware ha presentato PAG
Service [94], una soluzione proprietaria per la conversione automatica di applicazioni esistenti
per Tizen.
Seconda l’azienda, il processo di conversione di applicazioni esistenti ha innumerevoli vantaggi: permette di ridurre i costi di progetto, i tempi di sviluppo e di avere un time-to-market
bassissimo. Gli sviluppatori possono sviluppare a basso costo e pubblicare sul Tizen Store in
tempi brevi. Inoltre, per la piattaforma Tizen, avere più applicazioni a disposizione, significa rendere il sistema operativo più competitivo. Gli utenti non percepiscono differenze tra le
applicazioni native e convertite e possono accedere a software di alta qualità e performance,
indipendentemente dalla piattaforma utilizzata.
Attualmente la maggior parte degli sviluppatori per applicazioni mobili si concentra su iOS
ed Android. Inoltre, quest’ultimo detiene la maggiore quota di mercato. Uno strumento di
conversione automatica delle applicazioni disponibili per Android in Tizen, risulterebbe molto
interessante.
Android fornisce un ambiente di esecuzione “Hardware Indipendent”, basato sull’utilizzo di una
macchina virtuale. Il semplice porting dell’Android Runtime permette di eseguire le applicazioni
76
Sorgente immagine: http://download.tizen.org/misc/media/tds2013/slides/Publishing-to-Tizen.pdf
74
R App Player nell’architettura Tizen.76
Figura 27: POLARIS
per Android in Tizen. In più, se le i pacchetti applicativi vengono convertiti (repackaged) nel
formato TPK di Tizen, è possibile anche l’upload sul Tizen Store.
Il processo richiede 3 fasi:
R App Verifier, si controlla se l’applicazione è adatta alla
• Verifica: tramite POLARIS
conversione.
R App Generator (PAG) converte un’applicazione per Android,
• Generazione: POLARIS
in formato APK, al formato TPK per Tizen.
R App Player permette di eseguire un’applicazione tramite PAG
• Esecuzione: POLARIS
in Tizen, figura 27.
Secondo quanto riportato [95], i risultati dei test dimostrano che almeno il 50% delle applicazioni
R App Generator senza modifiche. Solo il 30%
possono essere convertite usando POLARIS
delle applicazioni richiede lievi modifiche. Il risultato finale dimostra come circa 80% delle
applicazioni per Android possano essere convertite ed utilizzate in Tizen.
Conclusioni dell’autore del report: Nonostante i diversi risvolti interessanti, eseguire applicazioni Android in una versione personalizzata dell’Android Runtime per Tizen, ha delle
implicazioni di sicurezza. Il modello di sicurezza di Android è differente da quello di Tizen.
Dalle informazioni fornite, non è deducibile come venga affrontato il problema della gestione dei
R
permessi per le applicazioni installate. In ultimo, non è chiaro quale sia il ruolo di POLARIS
App Player nel sistema operativo Tizen: se una semplice applicazione o un vero componente
di sistema.
4.6.2
WebGL
WebGL è una tecnologia multipiattaforma che fornisce un’API low-level per la gestione della
grafica 3D. Nel Maggio e nel Giugno 2011, Context Information Security pubblicò due report
[96] [97] che evidenziarono alcune criticità sulla sicurezza di WebGL, dimostrando come fosse
75
Figura 28: Esempio di attacco a WebGL con escalation of privileges.77
possibile ottenere degli screenshot dal dispositivo della vittima, con la possibile conseguente
perdita di dati sensibili. In seguito, Microsoft scelse di terminare il supporto di WebGL nel
proprio browser [98].
Tizen, nelle applicazioni Web, espone le API per accedere direttamente a WebGL.
Di seguito sono presentati alcuni punti di approfondimento:
• Il supporto dei browser per WebGL espone le funzionalità hardware direttamente sul web.
WebGL permette ad applicazioni web (tipicamente untrusted) di interagire direttamente
con i driver grafici (che operano in Kernel mode). La superficie di attacco di WebGL è
molto ampia ed espone codice privilegiato e non sufficientemente robusto. Il supporto
browser per WebGL richiederebbe ai driver grafici delle garanzie di sicurezza di cui mai
si era occupati fino ad ora. Se prima gli attacchi potevano risultare in un “escalation
of privileges” locale, ora lo possono diventare da remoto. Inoltre è lecito aspettarsi dei
bug solo su alcune piattaforme con hardware video specifico, facilitando attacchi mirati.
Nonostante OpenGL abbia delle funzionalità aggiuntive per permettere ai driver video
una validazione del codice 3D, queste sono da ritenersi incomplete. In Figura 28 sono
mostrate le fasi di un esempio di attacco WebGL.
• La responsabilità dei software di terze parti. La dipendenza del supporto browser per WebGL dai software di terze parti, è troppo alta per poter assicurare una navigazione web
sicura. I problemi di sicurezza potrebbero non manifestarsi direttamente nelle API di WebGL, ma nei vari componenti di sistema OEM o distribuiti da vari Indipendent Hardware
Vendors. Gli sviluppatori dei driver video non hanno mai affrontato questo problema,
essendo in genere esposti a codice trusted (quello del sistema) ed avendo fiducia che gli
77
Sorgente immagine: http://www.contextis.com/media/images/blog-WebGL-1.width-800.png
76
sviluppatori 3D non attaccassero le vulnerabilità. Inoltre il modello di aggiornamenti utilizzato nei driver delle schede video, caratterizzato spesso da update annuali, non soddisfa
le esigenze di un robusto “processo di aggiornamenti di sicurezza”.
• Possibili scenari DoS. Tradizionalmente le minacce di un Denial of Service lato client non
sono mai state considerate severe. L’infrastruttura grafica dei sistemi operativi non è stata
disegnata per difendersi da “ombre e geometrie” appositamente create da un attaccante.
Un sito web malevolo potrebbe portare al blocco del sistema ed alla necessità di reboot.
4.6.3
XSS
XSS è una vulnerabilità Cross-Browser, Cross-Piattaforma e Cross-Sistema operativo che permette di inserire ed eseguire codice Javascript lato client. Ne sono affette le applicazioni web
che elaborano dati provenienti da sorgenti non fidate e che non effettuano gli opportuni controlli. Un esempio è il campo di input di un form: se i dati non sono correttamente filtrati (ad
esempio rimuovendo il tag <script>) e sono inseriti direttamente nel DOM, è possibile iniettare
codice JavaScript da remoto, realizzando un attacco Cross Site Scripting.
Nonostante sia una vulnerabilità nota fin dai tempi dell’introduzione di JavaScript nel 1995,
raggiunge la sua massima popolarità nell’Ottobre 2005 con SamyWorm [99]. Attualmente
continua ad essere estremamente diffusa e la classifica Oswap la inserisce al terzo posto nella
Top Ten delle minacce per la applicazioni web del 2013 [100].
La crescita vertiginosa di Internet ha spinto gli sviluppatori dei browser ad aumentarne le
funzionalità per venire incontro alle nuove esigenze. Soluzioni di sicurezza e regole di buona
prassi sono state definite solo in seguito ad attacchi diffusi.
Di seguito viene presentata una lista dei principali attacchi ottenibili con la tecnica del Cross
Site Scripting [92].
• Website Defacement: modifica illecita di una o più pagine di un sito web.
• Session Hijacking: dirottamento di una sessione di lavoro autorizzata per ottenere un
accesso non autorizzato.
• Request Forger: invio di una richiesta al server all’insaputa del client.
• XSS Worms: codice JavaScript malevole in grado di diffondersi automaticamente.
• Clickjacking: reindirizza il click dell’utente a sua insaputa.
• JavaScript Keyloggers: uno sniffer in grado di intercettare, memorizzare ed inviare ad un
attaccante tutto quello che viene digitato sulla tastiera.
Le applicazioni Web, in Tizen, utilizzano le API estese di Javascript per accedere al sistema
operativo: l’accesso al File System, la comunicazione tra le processi, l’accesso ai servizi di
localizzazione, ai WebSocket ed a WebGL. Ogni nuova funzionalità per gli sviluppatori è anche
una nuova funzionalità per gli attaccanti. Le sole limitazioni sono le operazioni ammesse,
dichiarate nel file di Manifest. Le applicazioni Web di Tizen, realizzate in HTML e Javascript,
possono portare nuova popolarità a Cross Site Scripting.
Tutto nasce da un post su un blog [101]: una guida alla programmazione di una semplice
applicazione web che visualizza gli SMS ricevuti. Inviano un normale SMS, ad esempio con il
testo “Hey there!”, l’applicazione funziona correttamente, visualizzando il testo del messaggio.
77
Invece, se si invia un altro SMS contenente codice Javascript:
<script>alert(’Hey there!’)<script>
subito non succede nulla, ma riavviando l’applicazione si apre un pop up con scritto “Hey
there!”, l’inequivocabile segno di una vulnerabilità Cross Site Scripting.
Soluzioni La soluzione migliore è che sia il Framework a trattare questi problemi, gli sviluppatori non devono essere degli esperti di sicurezza per poter scrivere del codice sicuro.
• SDK dovrebbe fornire degli strumenti per aiutare gli sviluppatori a non inserire vulnerabilità di sicurezza come XSS. Ad esempio non dovrebbe essere possibile modificare
direttamente il DOM.
• Utilizzare delle librerie di JavaScript, come JQueryMobile, per il filtraggio e la codifica
dei dati.
• È comunque consigliato fornire delle regole di buona prassi ed insegnare agli sviluppatori
di applicazioni l’importanza di trattare correttamente i dati provenienti da fonti non
fidate.
4.7
Store
Figura 29: Screenshot che mostra alcune applicazioni scaricabili dal TizenStore.78
78
Sorgente immagine: http://www.tizenexperts.com/wp-content/uploads/2015/04/Samsung-SM-Z130HTizen-Smart-Phone-Tizen-Store-1.jpg
78
Figura 30: Le fasi del processo di revisione delle applicazioni.79
Il 3 maggio 2013 [102], apre il TizenStore, lo store ufficiale di Tizen: il negozio virtuale per il
download di applicazioni sia gratuite che a pagamento. Lo store è accessibile tramite un’applicazione dedicata, figura 29, oppure da Web, al seguente indirizzo http://www.tizenstore.com/.
Le applicazioni inviate dagli sviluppatori, prima di essere disponibili per il download, sono
sottoposte ad un processo di revisione.
4.7.1
Il processo di revisione
Il processo di revisione di Tizen [103] combina le metodologie utilizzate in Android, con quelle
dell’Apple App Review e promette di fornire una valutazione entro tre giorni dall’invio dell’applicazione. I pacchetti applicativi sono sottoposti ad un rigoroso processo di validazione del
codice e vengono analizzati con una combinazione di tecniche statiche e dinamiche [54].
Il processo di revisione si concentra su diversi criteri [104]: la verifica di sicurezza, il corretto
funzionamento, l’usabilità ed il controllo sull’adeguatezza dei contenuti esposti. La figura 30
mostra le fasi della verifica: la prima, Initial Inspection & Dynamic Analysis, è principalmente
automatizzata, la seconda, Content Review & Final Confirmation, viene eseguita da un revisore
finale.
Initial Inspection & Dynamic Analysis Inizialmente, viene effettuata un’analisi di sicurezza dinamica dove le applicazioni sono filtrate sulla base del rilevamento di possibili minacce:
malware, utilizzo non consentito di API privilegiate, riconoscimento di pattern che identificano
un attacco. Inoltre, viene verificato che a runtime l’applicazione non possa scaricare contenuto
esterno non validato.
In modo simile a Bouncer [105], il meccanismo di verifica usato da Android, il sistema di validazione di Tizen impiega una serie di emulatori per tracciare il comportamento dell’applicazione
79
Sorgente
immagine:
tizen validation guide ver 1.4 140529.pdf
https://developer.tizen.org/sites/default/files/documentation/
79
mentre se ne simula l’utilizzo, con l’obiettivo di scatenare ed intercettare possibili azioni malevoli. Successivamente, il Tizen Automation System controlla le funzionalità di base ed i metadati
associati all’applicazione, come l’adeguatezza del linguaggio utilizzato ed il supporto linguistico, il processo di installazione e disinstallazione, la gestione degli eventi e degli interrupt. Ad
esempio l’utente deve essere sempre in grado di poter effettuare una chiamata di emergenza e
di rispondere ad una in arrivo.
Review & Final Confirmation In questa fase l’applicazione viene validata sulla base delle
linee guida esposte nella Tizen Validation Guide. Si effettua un controllo sull’applicazione in
generale e su eventuali caratteristiche speciali ed infine il Content Review : una verifica sui
contenuti esposti, che devono essere adeguati al limite di età dichiarato, non devono infrangere i diritti di copyright e devono evitare possibili problemi culturali. In ultimo, un revisore
prende la decisione finale riguardo al processo di approvazione e viene inviato un responso allo
sviluppatore.
Il Tizen Validation Team ha segnalato [104] quali sono attualmente le principali cause di
rigetto delle applicazioni sottoposte a processo di revisione:
• Applicazioni over e sotto privilegiate: nel primo caso l’applicazione dichiara dei privilegi
per funzioni che non utilizza. Nel secondo, l’applicazione non viene accettata perché non
dichiara gli opportuni permessi necessari per accedere alle API utilizzate.
• Assenza di firma dello sviluppatore.
• Infrangimento del copyright o contenuti non adeguati: immagini o scritte che non rispettano i criteri esposti nella Tizen Validation Guide.
Per risolvere preventivamente i problemi di installazione e funzionamento, Samsung mette a disposizione il Remote Test Lab 80 . Si tratta di un servizio gratuito per gli sviluppatori, che tramite Web possono accedere remotamente a dispositivi fisici, per testare e configurare l’applicazione
prima della sottomissione.
4.7.2
Connessione alla Store
Non sono note informazioni circa la sicurezza della connessione al TizenStore: non è noto se
esista una fase di autenticazione e se il traffico di rete sia sottoposto a cifratura. Non è stata
possibile un’analisi ulteriore in quanto, attualmente, i dispositivi con Tizen installato sono
venduti nel solo mercato asiatico. Inoltre l’emulatore non dispone della TizenStore App e non
è possibile installarla: non è stato dunque fattibile effettuare un’analisi del traffico di rete.
Una nota interessante riguarda l’accesso al Tizen Store al di fuori di India e Bangladesh, gli
unici paesi in cui lo smartphone Samsung Z1, il primo dispositivo con Tizen installato nativamente, viene commercializzato. Al momento del login, usando l’applicazione dedicata, gli
utenti sono automaticamente connessi al Tizen Store del proprio paese sulla base del Mobile
Country Code (MCC) della scheda SIM o di GeoIP se nessuna scheda SIM è inserita. Su Internet sono disponibili dei tutorial per ovviare a questa limitazione [106], basati sull’utilizzo
di una connessione Virtual Private Network (VPN) per connettersi ad un server in India o in
Bangladesh.
80
http://developer.samsung.com/remotetestlab/rtlDeviceList.action
80
4.7.3
Store non ufficiali
Tizen accetta che le applicazioni siano scaricate anche da store differenti da quello ufficiale,
purché la firma del distributore utilizzata sia tra quelle accette dal sistema operativo. Esistono
alcuni store non ufficiali, distributori di applicazioni Web multipiattaforma, incluso Tizen.
Ciascuno applica un processo di revisione e policy personalizzate. Tra i principali: Appbackr81 ,
AppsFuel82 , Boostermedia83 , Ninja84 .
4.8
Cifratura
Tizen attualmente non fornisce funzionalità di cifratura del file system e non si hanno notizie
circa future implementazioni. Tuttavia, è disponibile la cifratura opzionale delle risorse di
un’applicazione web, di seguito dettagliata.
4.8.1
Cifratura applicazioni Web
Per le applicazioni Web che richiedono la cifratura nel file di configurazione config.xml,
<t i z e n : s e t t i n g e n c r y p t i o n=” e n a b l e ” />
il Web Runtime (WRT) fornisce la cifratura dei file HTML, Javascript e CSS (estensioni *.js,
*.html, *.css, *.xhtml) per la protezione delle risorse dell’applicazione [107]. La cifratura avviene
in fase di installazione dell’applicazione e non quando viene creato il pacchetto applicativo
(wgt) in fase di sviluppo, 4.2.4. Scopo della cifratura è quello di prevenire che le applicazioni
web vengano copiate tra dispositivi [108]. L’algoritmo di cifratura è AES, la chiave viene
generata con l’aiuto del modulo crypto del WRT, diversa per ogni file ed in seguito salvata nel
Secure Storage 4.9.2 [109]. Quando l’applicazione viene eseguita, il Web Runtime decifra i file
precedentemente cifrati in memoria in modo del tutto trasparente all’applicazione ed all’utente.
4.9
Componenti di sicurezza aggiuntivi
In questa sezione vengono presentati i restanti componenti di Tizen che implementano il modello
di sicurezza presentato in 4.4.
Attualmente Tizen fornisce diverse soluzioni alternative per la protezione dei dati sensibili:
• Il Tizen Key Manager, un deposito sicuro, protetto da password, per chiavi, certificati e
dati sensibili, viene descritto in 4.9.1.
• Il Secure Storage, una tecnologia per il salvataggio sicuro dei dati, descritta in 4.9.2.
• Gnome Keyring: essendo una soluzione di sicurezza comune ad Ubuntu Touch, viene
analizzato in Appendice 6.1.1.
81
http://www.appbackr.com/tizen
http://appsfuel.com/
83
http://www.boostermedia.com/
84
http://html5-ninja.com/
82
81
Data la similarità dei tre componenti, è possibile che nella versione 3.0 di Tizen solo il Key
Manager venga mantenuto85 .
In sezione 4.9.3, viene presentato il Content Security and Reputation Framework, per la scansione di dati e la classificazione di URL. In 4.9.4 una breve descrizione sulla sicurezza del modulo
WiFi ed in 4.9.5 una sezione dedicata alla gestione dei certificati SSL. A concludere 4.9.6, una
breve trattazione delle tecniche, presenti nel sistemi operativo, per la mitigazione degli exploit.
4.9.1
Tizen Key Manager
Figura 31: Architettura del Key Manager di Tizen.86
Il Key Manager di Tizen [110] fornisce un deposito sicuro, protetto da password, per chiavi,
certificati e dati sensibili. Permette, inoltre, operazioni crittografiche sui dati salvati, senza
rivelarne il contenuto in chiaro. In figura 31, sono mostrati i principali componenti.
Le API Il Key Manager fornisce due tipi di API: Secure Repository e Secure Crypto. Le
Secure Repository API espongono funzioni per immagazzinare, recuperare e rimuovere chiavi,
certificati e dati. Le Secure Crypto API forniscono funzioni crittografiche: creazione di una
coppia di chiavi asimmetriche, firma digitale e verifica dei certificati.
Regole di accesso Per i dati salvati nel Key Manager è possibile definire le seguenti regole
di accesso:
• Esportabile o Non-Esportabile Solo per i dati che sono contrassegnati come esportabili, il
Key Manager restituisce il valore in chiaro del contenuto. Altrimenti, mette a disposizione
del client delle funzioni crittografiche per poter utilizzare le chiavi ed i dati, senza rivelarne
il valore in chiaro.
85
Informazioni provenienti da una conversazione privata con Kidong Kim ([email protected]) autore
del codice del Secure Storage.
86
Sorgente immagine: https://developer.tizen.org/dev-guide/native/2.3.0/org.tizen.mobile.native.appprogramming/html/
82
• Protezione con password Tutti i dati nel Key Manager sono protetti dalla password dell’utente. Inoltre, un client può cifrare i dati usando una password addizionale, fornita al
momento dell’inserimento. Per ottenere i dati sarà necessario inserire la password ogni
volta.
Accesso ai dati Per default, solo il proprietario dei dati può accedere ai propri dati. Se
il proprietario fornisce l’accesso ad altre applicazioni, queste hanno il diritto di leggere e rimuovere i dati dal database. In ogni caso, quando un’applicazione viene cancellata, i dati e le
informazioni sul controllo degli accessi ad essa collegati, sono rimossi.
Figura 32: Schema delle operazioni al login ed al cambiamento di password dell’utente.87
User login e logout. Quando un utente effettua il login, il logout o cambia la propria
password, il LockScreen (4.10) e l’applicazione di Setting notificano il Key Manager tramite
specifiche API 88 .
Quando un utente effettua il login per la prima volta, figura 33, viene generata casualmente la
chiave DKEK (Domain Key Encryption Key). Se l’utente si scollega, logout, il DKEK viene cifrato con AES 256 bit con modalità GCM e salvato in memoria secondaria. La chiave utilizzata
nell’operazione di cifratura è la PKEK1, quest’ultima viene generata tramite la tecnica PBKDF2 89 , utilizzando HMAC-SHA512 con 4096 iterazioni, a partire dalla password dell’utente
unita con un Salt.
In riferimento a figura 32, al momento del login il Key Manager decifra il DKEK : viene utilizzata
la password dell’utente con un procedimento identico a quello descritto precedentemente per
la cifratura. Quando l’utente è loggato, la chiave DKEK si trova in chiaro in memoria. Al
momento di logout il Key Manager rimuove il DKEK dell’utente dalla memoria, quindi non è
più possibile accedere ai dati cifrati. Se l’utente cambia la propria password, il Key Manager
cifra il DKEK con la nuova password.
87
Sorgente immagine: https://wiki.tizen.org/w/images/a/a6/Key-manager-login.png
Per “login” si intente lo sblocco del dispositivo con password.
89
Password-Based Key Derivation Function 2 è una funzione in grado di derivare automaticamente una o
più chiavi segrete a partire da una password, usando una funzione di hash.
90
Sorgente immagine: https://wiki.tizen.org/w/images/2/2a/Key-manager-keyhierarchy.png
88
83
Figura 33: Dettagli di funzionamento del Key Manager.90
Funzionamento Il Key Manager fa uso di due chiavi per cifrari i dati dell’utente e delle
applicazioni:
• DDEK (Data Encryption Key for DB) è la chiave con cui viene cifrato il database di un
utente.
• ADEK (Application Data Encryption Key) è una chiave che viene allocata per ciascuna
applicazione, utilizzata per cifrare i propri dati.
Con riferimento alla Figura 33, vengono di seguito forniti ulteriori dettagli sul funzionamento
del Key Manager. Le chiavi DDEK e ADEK vengono generate casualmente quando l’utente
effettua il login per la prima volta. Durante il periodo di login dell’utente sono salvate in
chiaro in memoria. Quando l’utente si scollega, vengono cifrate con AES 256 bit con modalità
GCM, per essere salvate in modo sicuro in memoria secondaria. La chiave utilizzata è PKEK2
generata a partire da DKEK [riferimento al paragrafo precedente], tramite la tecnica PBKDF2,
utilizzando HMAC-SHA512 con un numero di iterazioni pari a 4096 91 .
Ulteriori dettagli Di seguito alcuni dettagli sul Key Manager ricavati dalla lettura codice
sorgente 92 :
• Il database di un utente cifrato viene salvato nel file /opt/data/ckm/db-uid.
• La chiave di un utente DKEK cifrata viene salvata nel file /opt/data/ckm/key-uid.
• La chiave di un utente DDEK cifrata viene salvata nel file /opt/data/ckm/db-key-uid.
91
Informazioni dettagliate sul funzionamento del Key Manager sono state ottenute anche dalla lettura del
codice sorgente.
92
https://review.tizen.org/git/?p=platform/core/security/key-manager.git;a=summary
84
• Nei path precedenti, il suffisso finale uid corrisponde con lo user id dell’utente attualmente
loggato.
4.9.2
Secure Storage
Secure storage è una tecnologia per il salvataggio sicuro dei dati utilizzato sia dai moduli della
piattaforma Tizen, che dalle applicazioni [111].
I dati confidenziali sono salvati in forma cifrata utilizzando l’algoritmo di cifratura simmetrica
AES-128 bit con modalità CBC (Cipher Block Chaining) 93 facendo uso della libreria OpenSSL.
La chiave viene generata alla prima esecuzione del secure-storage server e successivamente
salvata in chiaro 94 in un file il cui path viene specificato nel campo MASTER KEY PATH nel
file di configurazione /usr/share/secure-storage/config.
In seguito alla richiesta di informazioni allo sviluppatore 95 circa questa possibile vulnerabilità
di sicurezza, è stato risposto che il file è nascosto ed i permessi sono impostati consentono al
solo utente root di accedervi. Inoltre la chiave può essere sostituita con una hardware-fused key
nel caso in cui fosse disponibile una Trustzone nel dispositivo Tizen.
Le applicazioni accedono al servizio utilizzando le secure-storage client API per salvare, leggere
dati ed ottenere informazioni sui file salvati nel Secure Storage. La comunicazione con il securestorage server viene assicurata da meccanismi di Inter Process Communication. Quest’ultimo
verifica l’identità del chiamante utilizzando l’etichetta Smack del secure-storage client, se va a
buon fine, esegue l’operazione richiesta.
La chiave utilizzata per cifrare le applicazioni web 4.8.1, per proteggere il codice sorgente, viene
salvata nel Secure Storage.
4.9.3
Content Security and Reputation Framework
Dalla versione 2.1, Tizen integra il Content Security and Reputation Framework (CSF), presentato da Samsung ed Intel in collaborazione con McAfee [112] [113]. Si tratta di un Framework
per la scansione di dati e la classificazione di URL. Espone una collezione di API che possono
essere utilizzate per creare dei servizi volti ad incrementare la sicurezza del dispositivo.
Nel framework sono pensati due tipi di motori di scansione: scan engine e site engine [114]. Il
primo è pensato per ispezionare il contenuto di applicazioni, file e dati in memoria e può essere
utilizzato per la ricerca di Malware, Virus, Trojan e Spam. Il secondo adotta un sistema per
la reputazione dei siti web, in cui gli URL vengono classificati e vengono create delle policy di
accesso per ciascuna categoria (es. gioco d’azzardo, pornografia, spyware, etc.).
La sicurezza nei sistemi operativi mobile si è da sempre focalizzata sul controllo degli accessi, nel
tentativo di contenere i danni di un attacco. Tuttavia il problema della diffusione del malware
sulle piattaforme mobili [Introduzione 1.2.3] rende necessario adottare soluzioni preventive,
come la scansione dei file alla ricerca di signatures note, nonostante alcune limitazioni imposte
dalla capacità computazionale e dal consumo energetico [Introduzione 1.2.5].
93
Data la carenza di materiale informativo sul Secure-storage, informazioni tecniche sono state estrapolate
dalla lettura del codice sorgente.
94
Testato su emulatore.
95
Kidong Kim ([email protected]) autore del codice del Secure Storage.
96
Sorgente
immagine:
http://cdn.download.tizen.org/misc/media/conference2013/slides/
TDC2013-Content Security Framework.pdf
85
Figura 34: Schema dell’architettura del Content Security and Reputation Framework.96
Sebbene l’idea non sia nuova, difatti è alla base di tutti i software anti-virus, il modo in cui
questa è stata sviluppata nella piattaforma Tizen la rende straordinariamente interessante. Il
CSF è direttamente integrato nella componente di sicurezza del Core del sistema operativo
[Architettura 4.3.2], a differenza delle tradizionali soluzioni anti-virus operano a livello applicativo. Inoltre, per quanto riguarda la navigazione web, si vuole offrire un’esperienza più
sicura, con soluzione di sicurezza che mira a mitigare le minacce che sfruttano il fattore sociale
(social-engineering) portando l’utente a seguire link tendenziosi [Introduzione 1.2.5].
Il Content Security Framework è stato realizzato sul principio della leggerezza, di un’interfaccia
API unificata e di essere action driven: le applicazioni possono iniziare l’operazione di scansione
di ciò che desiderano, quando preferiscono. In aggiunta, essendo consapevoli dei dati che
gestiscono, è possibile bilanciare l’esigenza di sicurezza e di performance.
Il CSF, essendo un Framework, non offre un’implementazione del motore di scansione, che viene
invece fornita dal Security Engine Plug-In. La Tizen Association si limita a fornire delle linee
guida sulla sua realizzazione, ma ciascun membro può svilupparne la reale implementazione,
operando libere scelte sulla frequenza della scansione e sulla capacità computazionale richiesta. L’utente rimane libero di scegliere un’implementazione alternativa rispetto a quella a lui
proposta dall’OEM [115]. Inoltre, più Security Engines possono coesistere nella piattaforma,
anche se ciascuna applicazione può fare accesso ad un solo alla volta, ma può anche non esserne
presente alcuno. In Figura 34 è mostrato lo schema dell’architettura del CSF.
Il Content Security Framework offre un insieme di Security API per le applicazioni utente
e di sistema, un’interfaccia unificata per gli sviluppatori del Security Engine Plug-In ed un
meccanismo per la gestione dei plug-in.
In seguito vengono analizzati con maggiore dettaglio i motori di scansione che compongono il
Security Engine [116].
97
Sorgente
immagine:
http://cdn.download.tizen.org/misc/media/conference2013/slides/
TDC2013-Content Security Framework.pdf
86
Figura 35: Riepilogo delle operazioni di scansione e rilevamento malware.97
Scanning Engine - Content Security Engine L’implementazione è specifica del fornitore
del “Security Engine Plug-In”. Si ipotizza che l’operazione di scansione possa basarsi sulla
ricerca signatures note, oppure di pattern comportamentali noti, impiegando meccanismi euristici. In alternativa, per venire incontro alle limitazioni del dispositivo, si può decentralizzare
la ricerca, con connessione al cloud del fornitore della soluzione di sicurezza.
Le applicazioni client possono decidere autonomamente quando effettuare l’operazione di scansione, ad esempio validando il codice JavaScript prima del rendering di una pagina HTML. I
dati da controllare vengono passati al Framework con l’informazione sul tipo e le loro caratteristiche. Poter gestire in modo personalizzato il rilevamento di una minaccia è tutto a vantaggio
dell’utente, al quale viene offerta una migliore user experience.
Site Engine - URL Security Agent Fornisce un insieme API di per ottenere informazioni
sulla reputazione di un sito Web. Il fornitore del plug-in di sicurezza si occupa della classificazione e della definizione delle politiche di accesso. In seguito al rilevamento di una minaccia,
come mostrato in Figura 35, l’accesso all’utente può essere bloccato o essere rediretto ad una
pagina di notifica.
Di seguito, viene presentato un esempio di utilizzo, scritto in linguaggio C.
// I n i z i a l i z z a z i o n e
TCSLIB HANDLE hLib ; TCSErrorCode ErrCode ; TCSScanResult S c a n R e s u l t ;
hLib = TCSLibraryOpen ( ) ;
i f ( hLib == INVALID TCSLIB HANDLE) {
return −1;
}
// S c a n s i o n e d e i d a t i
i f ( TCSScanData ( hLib , &ScanParam , &S c a n R e s u l t ) == 0 ) {
...
87
}
// G e s t i o n e d e i r i s u l t a t i
i f ( S c a n R e s u l t . iNumDetected > 0 ) {
// R ile va me nt o d i una minaccia
S c a n R e s u l t . p f F r e e R e s u l t (& S c a n R e s u l t ) ;
}
TCSLibraryClose ( hLib ) ;
Alcuni dettagli aggiuntivi Il Security Plug-In viene installato insieme ai pacchetti applicativi di sicurezza e deve essere firmato con un trusted certificate per verificare l’autorizzazione.
Deve essere progettato e sviluppato per supportare la scansione simultanea da parte di molteplici thread. Il framework è implementato tramite librerie condivise: il Content Security Framework in libsecfw.so, il Security Engine Plug-In in libengine.so. Entrambe vengono caricate a
run-time nello spazio di indirizzamento del processo che invoca le Security API.
4.9.4
Wifi Security
In Tizen, Connection Manager (ConnMan) è il demone per la gestione della connettività di
rete. È comunemente usato nei sistemi embedded che eseguono il kernel Linux.
L’architettura WLAN di Tizen è centrata sul sottosistema wireless di Linux IEEE-802.11 98
costituito dai componenti cfg80211 e mac80211. ConnMan utilizza wpa supplicant per interfacciarsi con il dispositivo Wi-Fi [117]. Per ogni rete wireless a cui ci si collega, ConnMan salva le
password in chiaro nel file /var/lib/connman/default.profile [118], come mostrato nel seguente
esempio:
[ service home ]
Type = w i f i
Name = yourSSID
S e c u r i t y = wpa2−psk
P a s s p h r a s e = y ourP assP hras e
wpa supplicant supporta gli standard WPA e WPA2: implementa e gestisce l’autenticazione,
l’associazione e la negoziazione delle chiavi del driver WLAN con un autenticatore WPA, come definito dallo standard IEEE 802.11. Il modulo wpa supplicant, comune agli altri sistemi
operativi analizzati nel report, viene analizzato in Appendice 6.2.2.
4.9.5
Gestione dei certificati SSL
La piattaforma Tizen fornisce una collezione di certificati delle Certification Authority considerate trusted a livello di sistema per essere utilizzati da SSL (Secure Socket Layer) [119].
Le cartelle /etc/ssl/certs e /opt/share/cert-svc/certs/ssl sono link simbolici al direttorio /opt/etc/ssl/certs dove sono salvati tutti i certificati system trusted in formato PEM. Il nome di
ciascun file è il valore di hash del soggetto, che può essere ottenuto utilizzando il comando
OpenSSL come nell’esempio seguente:
o p e n s s l x509 −s u b j e c t h a s h o l d −noout
98
http://linuxwireless.org/welcome/
88
−i n c e r t i f i c a t o i n i n p u t
Inoltre, in Tizen, il file ca-certificate.crt ha al suo interno salvati tutti i certificati delle Certification Authority system trusted. Di seguito ne viene riportato un estratto.
sh −3.2# c a t / o p t / s h a r e / c e r t −s v c / ca−c e r t i f i c a t e . c r t
−−−−−BEGIN CERTIFICATE−−−−−
MIIEEjCCAvqgAwIBAgIPAMEAizw8iBHRPvZj7N9AMA0GCSqGSIb3DQEBBAUAMHAx
KzApBgNVBAsTIkNvcHlyaWdodCAoYykgMTk5NyBNaWNyb3NvZnQgQ29ycC4xHjAc
BgNVBAsTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEhMB8GA1UEAxMYTWljcm9zb2Z0
... ...
BOSoRQTIWjM4bk0cDWK3CqKM09VUP0bNHFWmcNsSOoeTdZ+n0qA=
−−−−−END CERTIFICATE−−−−−
−−−−−BEGIN CERTIFICATE−−−−−
MIIEIDCCAwigAwIBAgIQNE7VVyDV7exJ9C/ON9srbTANBgkqhkiG9w0BAQUFADCB
qTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf
... ...
In Tizen i certificati delle Certification Authority system trusted sono protetti da privilegi di
root. Anche se tutti gli utenti possono leggerli, sono l’utente root può modificarli.
Nel menù impostazioni, alla voce Sicurezza [120], è disponibile un’interfaccia grafica per la
visualizzazione dei Trusted root CA certificates e per la gestione dei certificati Utente, Figura
36.
Figura 36: Pagina principale del menù Impostazioni/Security.99
La prima opzione permette di visualizzare la lista ed i dettagli dei certificati salvati nel direttorio
/opt/etc/ssl/certs/, Figura 37.
Il menù per la gestione dei certificati utente permette l’inserzione e l’eliminazione di certificati
nella cartella /opt/share/cert-svc/pkcs12, Figura 38. Il formato dei certificati che possono essere
gestiti è limitato a PKCS12.
99
Sorgente immagine: https://wiki.tizen.org/wiki/Security/Tizen 2.X cert-svc-ui
Sorgente immagine: https://wiki.tizen.org/wiki/Security/Tizen 2.X cert-svc-ui
101
Sorgente immagine: https://wiki.tizen.org/wiki/Security/Tizen 2.X cert-svc-ui
100
89
(a) Prima figura
(b) Seconda figura
Figura 37: Visualizzazione dei certificati Trusted Root100
Figura 38: Interfaccia di gestione dei certificati utente.101
4.9.6
Tecniche di mitigazione degli exploit
Dalla versione 2.x Tizen supporta le applicazioni native, scritte in C/C++. Dal punto di vista
della sicurezza, il principale svantaggio è la possibile introduzione di vulnerabilità di tipo Stack
e Heap overflow ed underflow, format string, overflow degli indici dei vettori e variabili non
inizializzate. Per combattere possibili attacchi, sia a livello di sistema operativo, che applicativo,
la piattaforma Tizen offre una soluzione di mitigazione basata sull’utilizzo congiunto di ASLR
e DEP.
90
ASLR e DEP Address space layout randomization (ASLR) e Data Execution Prevention
(DEP) sono tecniche di mitigazione per gli exploit che sfruttano vulnerabilità esistenti non
ancora risolte [121]. ASLR e DEP non sono sostituti di un codice non sicuro, ma offrono
protezione per quelle vulnerabilità che non sono ancora state scoperte o pubblicate, riducendo
la probabilità di successo degli attacchi che prevedono la diretta manipolazione della memoria.
Per una breve descrizione sull’importanza e sul funzionamento di ASLR e DEP, fare riferimento
in Appendice alle sezioni 6.3 e 6.4.
ASLR in Tizen Nei dispositivi mobili, l’utilizzo di ASLR, incontra alcuni ostacoli. I sistemi
operativi per smartphone tentano di minimizzare il tempo di boot e di lancio delle applicazioni, il consumo della batteria ed il footprint della memoria. Queste ottimizzazioni rendono
l’implementazione tradizionale di ASLR insufficiente [122].
Nella piattaforma Tizen, non si è a conoscenza se tutti i componenti, deputati al funzionamento
di ASLR, siano implementati correttamente. Se ciò non fosse, un’implementazione incompleta
potrebbe lasciare aperta la strada ad attacchi che utilizzano indirizzi di ritorno che puntano ad
aree di memoria non randomizzate.
Nella documentazione, ASLR viene indicato come implementato a partire dalla versione di
Tizen 2.1. Nella sezione 4.12.2, vengono presentati i risultati di alcuni test sperimentali su
ASLR.
DEP in Tizen Data Execution Prevention, di default, non è completamente abilitato in
Tizen. I test su emulatore lo confermano. Per ulteriori dettagli sui test sperimentali, fare
riferimenti alla sezione 4.12.3.
Conclusione sulle tecniche di mitigazione ASLR e DEP dovrebbero essere sempre abilitati, anche se il loro utilizzo comporta un rallentamento del sistema. Per ottenere una difesa
superiore, andrebbero utilizzati in complemento con altre tecniche di mitigazione: estensioni del
compilatore, come StackGuard102 ed utilizzo di librerie wrapper, come Libsafe103 . Tuttavia, le
prime, per aver effetto, richiedono la ricompilazione di ogni file binario e le seconde potrebbero
non essere compatibili con tutti i programmi.
4.10
Protezione dell’accesso
Tizen fornisce un set di API [125] [126] per la gestione del blocco dello schermo, con o senza
password, ma il sistema operativo non rende disponibile alcuna applicazione che le implementi.
Anche nelle impostazioni di sicurezza dell’emulatore, non compare nessuna opzione a riguardo.
Implementazioni del LockScreen (schermata di blocco) sono fornite dall’OEM del dispositivo.
Ad esempio Samsung [127], nella versione dello smartphone SM-Z130h, fornisce 3 diverse opzioni
102
Nel 1997 venne introdotto StackGuard, un meccanismo volto a combattere gli attacchi buffer overflow su
stack. La protezione si basa sull’utilizzo del canary, chiamato anche cookie, modificato dinamicamente e salvato
prima del valore di ritorno. Un tentativo di modifica dell’indirizzo di ritorno, modificherà anche il valore del
canary, che causerà la terminazione del programma [123].
103
Libsafe previene gli exploit che tentano di sfruttare le vulnerabilità di tipo format string. Libsafe è una
libreria wrapper, che include una versione più sicura di alcune funzioni vulnerabili, come sprintf(). Se gli
argomenti passati alla funzione wrapper sono ritenuti sicuri, allora viene chiama l’originale, altrimenti viene
terminato il programma preventivamente [124].
104
Sorgente immagine: https://developer.tizen.org/sites/default/files/images/uioverview lock screen.png
91
Figura 39: Stack delle Viste della schermata di blocco.104
per lo sblocco dello schermo del dispositivo: swipe, pin e password. Di queste solo due, il pin
(numerico) e la password (alfanumerica), forniscono una protezione sicura nell’accesso, la prima
viene usata solo per scongiurare un uso involontario.
In figura 39 viene mostrato lo stack delle viste quando il dispositivo è bloccato: se il LockScreen
è attivo, è comunque possibile visualizzare delle notifiche.
La piattaforma Tizen non fornisce alcun meccanismo per il blocco del dispositivo e la cancellazione dei dati da remoto. È ragionevole aspettarsi soluzioni proprietarie, fornite dall’OEM del
dispositivo.
4.11
Vulnerabilità note
È disponibile un sistema di “bug tracking”105 dove, per la prima volta, è comparsa l’unica
vulnerabilità di Tizen nota. A quest’ultima è stato assegnato un identificativo CVE (Common
Vulnerabilities and Exposures).
CVE-2012-6459 ConnMan 1.3, in Tizen, continua a far visualizzare il bluetooth come servizio disponibile anche dopo che la modalità offline è stata abilitata [128]. ConnMan è un
demone di sistema incaricato della gestione dei servizi di connettività [Architettura 4.3]. Attaccanti remoti potrebbero ottenere informazioni sensibili tramite i pacchetti Bluetooth. Il
problema è stato risolto nella versione di ConnMan 1.5. Ne è affetta la versione Tizen IVI 2.11
e la vulnerabilità è stata resa nota il 1 Gennaio 2013 [129].
105
https://bugs.tizen.org/
92
4.12
Analisi Sperimentale
Per l’analisi sperimentale, è stata creata una semplice applicazione Web, successivamente eseguita sull’emulatore. Tramite il tool Smart Development Bridge (SDB), è stato possibile ottenere
una shell sul dispositivo con utente root (altrimenti non sarebbe stato possibile eseguire nessuno
dei comandi di seguito citati). La versione di Tizen testata è la 2.3.
4.12.1
Test Smack label
Il comando ls -lZ, eseguito nella home dell’applicazione, permette di visualizzare il security
context (l’etichetta) ed altre informazioni associate alle cartelle in formato esteso.
sh −4.1# l s
drwxr−xr−x
drwx−−−−−−
drwxr−xr−x
drwxr−xr−x
drwx−−−−−−
−l Z
2 root
3 app
3 root
5 root
2 app
root
app
root
root
app
p9SmpN6Z2i 4096 Mar 22
p9SmpN6Z2i 4096 Mar 22
p9SmpN6Z2i 4096 Mar 22
4096 Mar 22
p9SmpN6Z2i 4096 Mar 22
08:11
08:12
08:11
08:11
08:11
bin
data
res
shared
tmp
Dall’analisi dell’output è possibile verificare il modello di gestione dei permessi e di assegnazione
delle etichette, spiegato in sezione 4.5.
Gestione dei permessi Dalla seconda colonna dell’output del comando ls, è possibile notare
la presenza dei due utenti di Tizen 2.X: l’utente root ed app. Il primo è proprietario di tutti i
direttori, ad eccezione di data e tmp di proprietà dell’utente app. I permessi sono impostati in
accordo con quanto spiegato in 4.5.3. Da notare che solo l’applicazione stessa ha libero accesso
in lettura (r) e scrittura (w) ai propri dati (data) ed ai file temporanei (tmp).
Assegnazione di etichette Smack Alle cartelle bin, data, res e tmp viene associata l’etichetta p9SmpN6Z2i 106 , invece a shared, l’etichetta floor ( ). Come descritto nel paragrafo 4.5.2,
associare l’etichetta p9SmpN6Z2i all’applicazione permette di implementare il Sandboxing: solo il processo etichettato p9SmpN6Z2i potrà accedere alle risorse dell’applicazione. Viceversa,
l’utilizzo dell’etichetta floor ( ) consente sempre accesso in lettura [Smack 4.5.1], permettendo
di implementare una soluzione di condivisione tra le applicazioni senza necessità di definire
nuove regole Smack più specifiche ad ogni nuova installazione.
4.12.2
Test ASLR
ASLR in Tizen è abilitato a livello kernel, infatti eseguendo il comando:
cat /proc/sys/kernel/randomize va space
il risultato è 2, indicando la completa randomizzazione dello spazio di indirizzamento di un
processo. Tuttavia, in Tizen 2.1 [130], il valore di /proc/self/personality era settato a 00040000,
che corrispondeva a ADDR NO RANDOMIZE, cioè ASLR disabilitato. Il problema è stato
successivamente risolto in Tizen 2.2 dove il valore di /proc/self/personality è stato impostato
a 00000000.
Per controllare se effettivamente ASLR fosse funzionante, si è deciso di eseguire la stessa
applicazione di test più volte e di utilizzare il comando
106
L’ApplicationID assegnato all’applicazione è p9SmpN6Z2i.SMSa.
93
cat /proc/[pid]/maps
per monitorare il posizionamento dello stack e dello heap nello spazio di indirizzamento.
Prima esecuzione:
sh −4.1# c a t / pro c /2500/ maps | g r e p −E ’ v d s o | heap | s t a c k | Web ’
08048000 −08049000 r−xp 00000000 f e : 0 0 4524
/ u s r / b i n / WebProcess
08049000 −0804 a000 rw−p 00001000 f e : 0 0 4524
/ u s r / b i n / WebProcess
0924 a000 −0946 e000 rw−p 00000000 0 0 : 0 0 0
[ heap ]
b0f9b000−b179b000 rwxp 00000000 0 0 : 0 0 0
[ stack :2505]
b179c000−b 1 f 9 c 0 0 0 rwxp 00000000 0 0 : 0 0 0
[ stack :2504]
b2456000−b2c56000 rwxp 00000000 0 0 : 0 0 0
[ stack :2503]
b7720000−b7721000 r−xp 00000000 0 0 : 0 0 0
[ vdso ]
bfe5d000−b f e 7 e 0 0 0 rwxp 00000000 0 0 : 0 0 0
[ stack ]
Seconda esecuzione:
sh −4.1# c a t / pro c /2601/ maps | g r e p −E ’ v d s o | heap | s t a c k ’
09319000 −09519000 rw−p 00000000 0 0 : 0 0 0
[ heap ]
b0f95000−b1795000 rwxp 00000000 0 0 : 0 0 0
[ stack :2607]
b1796000−b 1 f 9 6 0 0 0 rwxp 00000000 0 0 : 0 0 0
[ stack :2605]
b2450000−b2c50000 rwxp 00000000 0 0 : 0 0 0
[ stack :2604]
b771a000−b771b000 r−xp 00000000 0 0 : 0 0 0
[ vdso ]
bfc32000 −b f c 5 3 0 0 0 rwxp 00000000 0 0 : 0 0 0
[ stack ]
Terza esecuzione:
sh −4.1# c a t / pro c /2625/ maps | g r e p −E ’ v d s o | heap | s t a c k ’
08998000 −08 b98000 rw−p 00000000 0 0 : 0 0 0
[ heap ]
b1023000−b1823000 rwxp 00000000 0 0 : 0 0 0
[ stack :2631]
b1824000−b2024000 rwxp 00000000 0 0 : 0 0 0
[ stack :2630]
b24de000−b2cde000 rwxp 00000000 0 0 : 0 0 0
[ stack :2629]
b77a8000−b77a9000 r−xp 00000000 0 0 : 0 0 0
[ vdso ]
bfdd9000−b f d f 9 0 0 0 rwxp 00000000 0 0 : 0 0 0
[ stack ]
Dall’output è evidente come lo stack, lo heap e vDSO107 cambino il loro indirizzo di memoria
(indicato nella prima colonna a sinistra) ad ogni esecuzione, dunque è possibile affermare che
ASLR è attivo.
4.12.3
Test DEP
Lo stesso comando utilizzato nel test di ASLR, cat /proc/self/maps — grep -E ’(stack — heap)’,
può essere usato anche per verificare se DEP è abilitato.
Osservando parte dell’output del test di ASLR, in particolare i campi sui permessi (ultima
colonna a destra)
08998000 −08 b98000 rw−p 00000000 0 0 : 0 0 0
b1023000−b1823000 rwxp 00000000 0 0 : 0 0 0
[ heap ]
[ stack :2631]
si nota come che lo stack, a differenza dell’heap, sia impostato come eseguibile (x), dunque
DEP non è abilitato.
107
http://man7.org/linux/man-pages/man7/vdso.7.html
94
4.13
Conclusioni
In Tizen la sicurezza è un fattore dominante ed è stata presa seriamente in considerazione
in fase di progettazione. Dall’architettura al processo di revisione delle applicazioni, in tutto
si può riconoscere l’impegno di avere adottato le migliori soluzioni e di avere saputo trarre
insegnamenti dalle minacce esistenti nel panorama mobile degli ultimi anni.
Il software è completamente open source, in gran parte ereditato da progetti con una lunga
storia alle spalle e maturi dal punto di vista della sicurezza.
Tizen è un laboratorio sperimentale in cui sono state proposte soluzioni di sicurezza completamente innovative. La sua storia lo rende unico ed incredibilmente favorito sotto l’aspetto
progettuale e della sicurezza in particolare. È il risultato della fusione di diversi sistemi operativi, provenienti da ambienti diversi, con differenti background e priorità distinte. Solo le
migliori tecnologie, tra quelle disponibili, sono state scelte e dove nulla era presente sono state adottate nuove soluzioni. Il Content Security Framework [4.9.3] e Vasum [4.5.11] ne sono
un esempio e sono cosı̀ interessanti da poter essere proposta la loro adozione in altri sistemi
operativi Mobile.
Per certi aspetti la sicurezza in Tizen può essere definita complessa, nonostante le idee di base,
come l’utilizzo di etichette per il controllo degli accessi e la definizione di “privilegi astratti”
per le operazioni sensibili, siano molto semplici. Nella release 2.0 di Tizen, un tentativo di
semplificazione ha portato le regole Smack a crescere fino al numero di 40000, rendendole
ingestibili. Nella 3.0, con l’adozione del “Three domain model” le regole diminuiscono, ma
vengono aggiunti nuovi componenti: Cynara ed il Security Manager. In futuro per supportare
nuove funzionalità, come il multi-utente [57], sarà necessario introdurne altri.
Esiste, comunque, un margine di miglioramento, rendendo obbligatorie molte scelte opzionali,
come l’utilizzo di Data Execution Prevention [4.12.3] ed integrando nell’IDE nuovi tool per la
prevenzione di attacchi di tipo Cross Site Scripting [4.6.3].
Non sono date informazioni specifiche sul processo di revisione delle applicazioni pubblicate
sullo Store e non è chiaro quali siano i criteri di filtraggio delle applicazioni over-privilegiate o
malevoli.
Nonostante dal punto di vista teorico, grazie all’implementazione sia del modello DAC che
MAC, le soluzioni adottate siano più sicure di quelle utilizzate da Android ed iOS, Tizen rimane
un progetto giovane, che non ha ancora raggiunto la maturità necessaria per essere definito
più sicuro. Se la sua diffusione continuerà a crescere, la comunità internazionale dedicherà
inevitabilmente sempre più attenzione e possibili falle saranno scoperte e risolte.
Attualmente, il più grosso limite di Tizen è rappresentato dagli sviluppatori delle applicazioni,
che non hanno ancora maturato un vero interesse verso questa piattaforma. In tal senso è da
considerare molto interessante la soluzione proposta per permettere un’automatica conversione
della maggioranza delle applicazioni sviluppate per Android [4.6.1].
95
5
Conclusioni
La seguente tabella riassume i punti di maggiore interesse dei tre sistemi operativi analizzati.
Ubuntu Touch
Nasce con l’intento di portare Ubuntu anche sui dispositivi mobile. L’idea
alla base del suo sviluppo è di ottenere un sistema operativo congiunto
mobile-desktop. Dal punto di vista della sicurezza vengono utilizzate soluzioni già esistenti (AppArmor) ed integrate con
nuovi strumenti in grado di renderne più semplice l’utilizzo da parte
degli sviluppatori (Policy
Groups).
È la stessa di Ubuntu
14.04 LTS con l’aggiunta
di LXC, per la funzione di
container per i driver Android, riutilizzati per l’interfacciamento con l’hardware. Rispetto alle versioni precedenti di Ubuntu, è stato modificata soprattutto Unity, l’interfaccia utente, adattata anche a schermi di formato diverso dagli standard
desktop.
QML (solo locale), HTML
(locale o su web)
CyanogenMod
È una Mod di Android,
cioè una “variante” maggiormente personalizzabile
e con meno restrizioni, in
grado di accontentare una
fetta di utenza sempre crescente. Utilizza gli stessi meccanismi di sicurezza di Android, ma aggiunge un maggiore controllo
sulla gestione dei permessi
concessi alle applicazioni.
Tizen
È il risultato della fusione di diversi sistemi operativi esistenti. La sicurezza è un fattore dominante ed è stata presa seriamente in considerazione in fase di progettazione. Adotta le migliori soluzioni ed essendo il più
giovane, fa tesoro dei progressi raggiunti, negli ultimi anni, dalla sicurezza in
ambito mobile.
È la stessa di Android.
L’architettura è costituita da quattro componenti chiave: il Kernel (Linux), il Core (implementazione dei servizi di base),
il Framework Web ed il
Framework Nativo (a supporto dei rispettivi tipi di
applicazione).
Java, LUA108 , HTML
Confinamento Basato su AppArmor (sul
delle
modello MAC). Gli svilupapplicazioni
patori dichiarano all’interno di un file di manifest
i privilegi di cui l’applicazione ha bisogno. Sulla
base di questi viene generato automaticamente, al
momento dell’installazione, il profilo AppArmor
corrispondente.
Basato sul modello DAC.
Viene riutilizzato il sistema tradizionale dei permessi Unix basato sugli
utenti: ogni applicazione
ha un User Id diverso.
Native
(C++),
Web
(HTML, CSS e Javascript) ed Ibride (Web +
Native)
In Tizen 2.0, tramite l’utilizzo congiunto di Smack
(modello MAC) e dell’assegnazione di permessi di
accesso al file system, specifici per utenti e gruppi
(modello DAC). In Tizen
3.0 si aggiunge un nuovo
componente, Cynara, un
policy checker.
Origine
Architettura
Applicazioni
supportate
108
Tramite Corona SDK [131].
96
Gestione dei
permessi delle applicazioni
Sfrutta i Thrusted Helpers: servizi per la gestione dell’accesso alle risorse di sistema da parte di un’applicazione. La
comunicazione con i Thrusted Helpers è possibile
solo se il profilo AppArmor lo consente. Questi
servizi mostrano all’utente
un prompt di richiesta autorizzazione, memorizzando la scelta, che comunque rimane modificabile in
seguito.
Distribuzione Ubuntu Apps Directory
applicazioni
e fonti aggiunte manualmente.
Secondo il modello Android i permessi vengono
concessi solo al momento
dell’installazione e non sono più modificabili. CyanogenMod funziona allo
stesso modo, ma consente successivamente di rimuovere determinati permessi. Allo stesso tempo,
permette di elevare i privilegi di una applicazione
a quelli di amministratore,
al fine di consentire le funzionalità aggiuntive che lo
distinguono da Android.
Google Play Store e fonti
aggiunte manualmente.
Le applicazioni dichiarano
i permessi richiesti nel file di Manifest, ma quelli realmente concessi dipendono dalla tipologia di
firma utilizzata dal distributore. Tramite il pannello Privacy Manager nel
menù Settings, è possibile a posteriori la modifica
delle regole di accesso.
Verifica delle applicazioni nello Store
Processo automatico o
manuale a seconda delle
autorizzazioni
richieste
tramite i Policy Groups.
Processo in parte automatico ed in parte manuale
Firma delle
applicazioni
Esecuzione
delle
applicazioni
come utente
root 110
Mercato delle applicazioni
Store e, opzionalmente,
sviluppatore.109
NO
Solo sviluppatore.109
SI
Lo store ufficiale di Tizen
è il TizenStore. Distributori alternativi sono possibili, purché la firma utilizzata sia riconosciuta dal
sistema operativo.
Il processo di revisione del
TizenStore richiede due
fasi: la prima, Initial Inspection & Dynamic Analysis, è principalmente automatizzata, la seconda,
Content Review & Final Confirmation, viene
eseguita da un revisore
finale.
Firma dell’autore e del
distributore
NO
Molto piccolo
Molto grande
Medio
Tabella 2: Tabella di confronto tra i tre sistemi analizzati.
Nel corso dell’analisi è stato dimostrato come anche i sistemi operativi mobile meno diffusi (collettivamente quelli analizzati rappresentano meno dell’1% del mercato) facciano della sicurezza
un aspetto centrale della progettazione. I numerosi canali di attacco, di cui si è parlato nell’Introduzione 1.2.3, rendono difficile affrontare il problema della sicurezza puntualmente per ogni
minaccia e poiché il malware oggi riveste un’importanza particolare, ciò che accomuna tutti e
109
110
Non è richiesto per le app scaricate da fonti non ufficiali.
Si intende la possibilità di dare alle applicazioni privilegi di amministratore.
97
tre i sistemi analizzati, è l’isolamento delle applicazioni. Le tecniche di confinamento permettono di risolvere in un’unica soluzione diversi problemi di sicurezza. È interessante notare, come
mostrato in Tabella 5, che i tre sistemi operativi adottino tutti soluzioni differenti, nonostante
l’idea di base sia condivisa. Mentre Ubuntu Touch e CyanogenMod utilizzano soluzioni già
esistenti, in Tizen si è scelto di adottare nuovi componenti, anche se in parte basati su modelli
noti.
In tutti e tre i sistemi analizzati esiste la volontà di semplificare la gestione della sicurezza, sia
dal lato utente che sviluppatore. Il primo caso è testimoniato dalla capacità di mostrare, in
modo facilmente comprensibile, i permessi associati ad una applicazione e di fornire interfacce
intuitive per la loro gestione. Inoltre, in tutti e tre i sistemi operativi, i permessi sono stati
definiti sulla base di servizi astratti e non dei componenti di sistema che li implementano, facilitandone la comprensione. Ubuntu Touch mostra i privilegi di un’applicazione sia in fase di
installazione, che al momento del primo utilizzo. CyanogenMod li mostra solo in fase di installazione, ma consente di modificarli in un secondo momento. Al momento dell’installazione Tizen
non richiede all’utente di accettare i privilegi di un’applicazione, ma ne permette la gestione
a posteriori. A proposito, si sottolinea che mentre le applicazioni per Ubuntu Touch e Tizen
sono in grado di gestire il caso in cui venga revocato un permesso, quelle per CyanogenMod,
essendo le stesse di Android, non possiedono normalmente questa capacità. Dunque, in CyanogenMod revocare alcuni privilegi successivamente all’installazione rischia di minare l’instabilità
di un’applicazione. Dal punto di vista dello sviluppatore, la gestione della sicurezza è semplifica in quasi tutti i sistemi, anche grazie all’impiego di SDK evoluti (l’SDK di CyanogenMod
è lo stesso di Android). UbuntuTouch mette a disposizione semplici strumenti per specificare
i permessi necessari all’applicazione in sviluppo. Al contrario, in Tizen ci sono dei margini di
miglioramento, soprattutto per agevolare la scrittura di codice sicuro, come spiegato in 4.6.3.
Dal punto di vista della sicurezza offerta dalla distribuzione ed installazione delle applicazioni,
sono emersi tre diversi modelli:
• CyanogenMod utilizza lo stesso negozio virtuale di Android, Google Play. Il processo di revisione è prevalentemente automatico, solo ultimamente è stato affiancato dalla possibilità
di controllo manuale. È richiesto che le applicazioni siano firmate solo dallo sviluppatore.
• In Ubuntu Touch le applicazioni sono sempre firmate dallo store che le distribuisce e, in
modo opzionale, anche dallo sviluppatore. Anche in questo caso è prevista la possibilità
di revisione manuale delle applicazioni. Non si è in possesso di dati concreti al riguardo,
tuttavia si presuppone che gli strumenti di controllo automatico delle applicazioni, utilizzati nello store di Ubuntu Touch, non siano avanzati come quelli di Google Play, che al
contrario vanta diversi anni di esperienza.
• Tizen presenta il modello più sicuro: è richiesto infatti che l’applicazione sia firmata sia
dallo sviluppatore, che dal distributore. Il Tizen Store sottopone i pacchetti applicativi
ad un rigoroso processo di validazione del codice, analizzandoli con una combinazione di
tecniche statiche e dinamiche. La verifica consta di due fasi, la prima è principalmente
automatizzata, la seconda viene eseguita da un revisore finale.
Dall’analisi emerge la caratteristica distintiva di CyanogenMod: l’unico a lasciare all’utente la
possibilità di “fidarsi” di un’applicazione concedendole privilegi di amministratore. In queste
condizioni, in caso di applicazione malevole, le conseguenze sarebbero devastanti. Ubuntu
Touch e Tizen applicano un modello di sicurezza differente, dove l’utente non è fidato, vietando
in principio la possibilità di concedere autorizzazioni potenzialmente dannose.
98
Al momento, i sistemi operativi trattati possiedono collettivamente una fetta molto piccola di
un mercato dominato principalmente da Android ed iOS. Gli utenti sono sempre più alla ricerca
di semplicità ed integrazione tra i dispositivi, ragione per cui si pensa che saranno solo i sistemi
più diffusi a sopravvivere. Ubuntu Touch, dato il progetto di integrazione con Ubuntu, potrà
diffondersi specialmente tra gli utilizzatori della versione desktop. Tizen è un sistema operativo
giovane, attualmente impiegato solo in pochi dispositivi di fascia bassa, soprattutto nel mercato
asiatico. Possiede tutti i presupposti necessari per ottenere, in futuro, una sua fascia di mercato.
CyanogenMod, al contrario, è un sistema già affermato. Tuttavia, le possibilità di crescita sono
ancora grandi, essendo l’unico in grado di accontentare le esigenze di una crescente fascia di
utenti competenti, alla ricerca di innovazione.
99
6
Appendice
6.1
Memorizzazione dati critici
Sia in ambiente mobile che desktop, le applicazioni possono avere il bisogno di salvare dati critici,
come password, in modo “sicuro”. Sebbene ogni applicazione possa utilizzare una propria
soluzione al problema, un sistema centralizzato di gestione dei dati critici, fornito dal sistema
operativo, è conveniente sotto diversi aspetti:
• Permette all’utente di avere una chiara visione e facile gestione dei dati critici salvati dalle
varie applicazioni.
• Concentrare la funzionalità in un unico modulo facilita il processo di aggiornamento nel
caso in cui venisse scoperta una vulnerabilità.
• Consente la condivisione di un segreto tra applicazioni.
• Permette di utilizzare password più sicure (più lunghe e complesse) in quanto esse possono
essere memorizzate in questo modulo e protette con un’unica password da ricordare. Tuttavia, proteggere più segreti con un’altro segreto determina che se un attaccante scoprisse
il secondo avrebbe accesso a tutti gli altri. È dunque importante scegliere una password
molto sicura a questo scopo.
Soluzioni di questo tipo sono note con il nome “keyring”: un portachiavi, contenitore di segreti.
In Linux, una soluzione di keyring molto diffusa, che sarà prossimamente adottata in Ubuntu
Touch e che è attualmente inclusa in Tizen, è GNOME Keyring. Essendo una soluzione ideata
per ambiente desktop, nella sua descrizione utilizzeremo il concetto di login, che in ambito
mobile coincide con lo sblocco del dispositivo.
6.1.1
GNOME Keyring
GNOME Keyring è un’applicazione demone111 per la gestione di dati critici. Viene utilizzato
per la memorizzazione di segreti, password, chiavi, certificati, resi disponibili alle applicazioni
che vi accedono tramite apposite API. I dati sensibili sono cifrati e memorizzati in file situati
nella cartella home dell’utente112 . Lo scopo di GNOME Keyring è di proteggere l’utente da:
• Furto di password dal dispositivo nel momento in cui è spento accedendo fisicamente alla
memoria secondaria (hard disk).
• Lettura delle password dalla memoria RAM dopo che l’utente ha effettuato il logout,
oppure dall’area di swap del disco.
• Lettura di keyring appartenente ad un altro utente113 .
• Furto di passwords da keyring bloccati.
111
Nei sistemi Unix, e più in generale nei sistemi operativi multitasking, un demone (daemon in inglese) è un
programma eseguito in background, che fornisce un servizio.
112
I sistemi operativi analizzati in questo report sono tutti basati su Linux ed utilizzano il Linux File System,
caratterizzato da una cartella home per ogni utente.
113
Al momento i sistemi operativi mobili sono monoutente. Ubuntu Touch nella versione per tablet è in via
di divenire multiutente [132]. Tizen 3.0 sarà un sistema multiutente.
100
Il demone può gestire diversi portachiavi, keyring, ciascuno associato ad un file diverso situato
in /.gnome2/keyrings/ e con i propri segreti. Ogni portachiavi può trovarsi nello stato bloccato
o sbloccato. Nel primo caso, il corrispondente file è cifrato tramite l’algoritmo AES-128 bit. La
chiave di cifratura è ricavata da quella specificata dall’utente al momento della creazione del
keyring, combinata con un sale, su cui è eseguito iterativamente (in numero compreso tra 1000
e 2000) l’algoritmo di hash SHA-256.
Nel momento in cui un keyring viene sbloccato (sotto richiesta di una applicazione tramite le
API a disposizione, oppure automaticamente al login, come descritto in seguito), viene decifrato
ed il risultato, in plain text, viene caricato in RAM.
Avere il contenuto di un keyring in chiaro in RAM può essere rischioso dal punto di vista della
sicurezza. Infatti, sarebbe soggetto ad attacchi che sfruttano memory dumping e swapping 114 .
Quest’ultima operazione potrebbe scrivere sull’hard disk dati sensibili in chiaro: avere accesso
al disco fisico significherebbe avere accesso a tali dati. Al fine di eliminare questo rischio,
GNOME Keyring utilizza la chiamata di sistema mlock() che consente di allocare in RAM una
certa quantità di memoria non soggetta a swapping.
In GNOME keyring, due portachiavi hanno funzioni particolari:
• Il portachiavi di sessione. Non è associato ad alcun file in quanto non viene mai scritto
su disco: viene creato al momento del login dell’utente, salvato in memoria RAM ed
eliminato al logout. Le applicazioni possono utilizzarlo per salvare segreti temporanei.
• Il portachiavi di default, chiamato “login”, protetto dalla stessa password di login. Al momento del login dell’utente, il modulo PAM (Pluggable Authentication Modules) comunica
con GNOME Keyring e gli fornisce la password appena inserita al fine di decifrare automaticamente il keyring login, che è cosı̀ sbloccato. Il keyring viene poi automaticamente
ri-bloccato al logout.
I segreti sono memorizzati all’interno dei keyring sotto forma di items. Ogni item ha un nome,
un segreto e una lista illimitata di attributi. Ogni attributo consiste in una coppia chiave-valore,
che può essere utilizzata dalle applicazioni per la ricerca di tale segreto all’interno del keyring.
Di seguito un esempio del contenuto di un keyring non cifrato.
$ cat f o o . k e y r i n g
[ keyring ]
d i s p l a y −name=f o o
c t i m e=0
mtime=0
l o c k −on−i d l e=f a l s e
l o c k −a f t e r=f a l s e
[1]
item−type=0
d i s p l a y −name=key1
s e c r e t=p a s s 1
mtime =1311897928
c t i m e=0
[2]
114
Ogni sistema operativo normalmente può trasferire temporaneamente dati dalla memoria all’hard disk al
fine di incrementare virtualmente la quantità di memoria disponibile.
101
item−type=0
d i s p l a y −name=key2
s e c r e t=p a s s 2
mtime =1311900380
c t i m e=0
Possibili attacchi Sebben GNOME Keyring sia una soluzione semplice e sicura, è vulnerabile
ad alcuni tipi di attacco:
• Attacco brute-force offline, per scoprire la password di cifratura di un keyring.
• Attacco cold boot [133]. Consiste nel forzare lo spegnimento istantaneo del dispositivo (ad
esempio rimuovendone la batteria) nel momento in cui uno o più keyring sono sbloccati.
La natura circuitale della maggior parte delle memorie RAM fa si che l’informazione sia
mantenuta per alcuni secondi/minuti anche in mancanza di alimentazione. Dunque i dati
salvati in RAM sarebbero accessibili avendo diretto accesso ad essa utilizzando un secondo
dispositivo, oppure eseguendo il boot tramite un sistema operativo secondario. Si tratta
di un attacco teoricamente fattibile, ma in pratica tecnicamente complesso.
Considerazioni sull’adozione del Keyring nei sitemi operativi mobile. GNOME keyring è una soluzione pensata per dispositivi desktop, dove le applicazioni non sono isolate le
une dalle altre: consente ad ogni applicazione eseguita dall’utente autenticato di accedere alle
informazioni contenute nei keyring sbloccati. In ambito mobile è necessario introdurre una
separazione tra le applicazioni, in modo che ciascuna sia in grado di specificare le regole di
accesso al proprio keyring.
6.2
Sicurezza delle connessioni di rete
Nell’intento di analizzare le caratteristiche di sicurezza dei sistemi operativi mobile trattati,
la maggior parte del report si concentra sugli aspetti di sicurezza interni al sistema, relativi
soprattutto alla protezione a livello software: isolamento delle applicazioni, gestione privilegi,
firma della applicazioni. Trattandosi di dispositivi mobili, una componente di sicurezza importante è rappresentata delle comunicazioni con l’esterno, principalmente tramite WiFi e rete
cellulare GSM. Per ovvie ragioni di interoperabilità tra diversi dispositivi, le soluzioni qui adottate sono regolamentate da standard internazionali. Tuttavia, vista l’importanza che rivestono
nel campo della sicurezza mobile, riteniamo opportuno fornire una breve descrizione di alcuni
dei meccanismi di sicurezza adottati.
6.2.1
GSM
Nelle comunicazioni via GSM si distinguono due parti principali: la stazione mobile (lo smartphone o tablet, contenente una scheda SIM) e l’operatore GSM (che comunica tramite le stazioni base). La sicurezza del GSM prevede l’autenticazione della stazione mobile e la cifratura
dei dati trasmessi. L’operatore non è autenticato, tuttavia, come viene in seguito spiegato, è
impossibile per un falso operatore decifrare i dati inviati dalla stazione mobile.
Con riferimento a Figura 40, viene di seguito fornita una descrizione generale del protocollo di
autenticazione e cifratura utilizzato nel GSM 115 . Si suppone che l’operatore abbia già ricevuto
115
Viene tralasciata la descrizione degli algoritmi A3, A5, A8 utilizzati.
102
dalla stazione mobile comunicazione dell’IMSI ( International Mobile Subscriber Identity) della
SIM, numero che la identifica univocamente.
Figura 40: Sorgente immagine: Schema di autenticazione e cifratura nel GSM.116
1. L’operatore genera una stringa casuale di 128 bit, chiamata RAND, che invia alla stazione
mobile.
2. La stazione mobile e operatore calcolano, utilizzando l’algoritmo A3 e la chiave segreta Ki
di 128 bit, associata alla SIM, il valore SRES = A3(Ki , RAN D). L’operatore conosce Ki
dai propri registri, tenuti segreti, mentre la stazione mobile contiene tale dato all’interno
della SIM.
3. La stazione mobile invia SRES all’operatore, che lo confronta con quello da lui calcolato
per verificarne l’uguaglianza.
4. Stazione mobile e operatore calcolano la chiave di cifratura di 64 bit come Kc = A8(RAN D, Ki ).
5. Le future comunicazioni sono cifrate con l’algoritmo A5 (stream cipher, implementato
efficientemente in hardware) e la chiave Kc .
Come visibile in Figura 40, gli algoritmi A3 e A8 sono implementati direttamente in hardware
sulla SIM. Ciò è fondamentale ai fini della sicurezza, in quanto consente di non rendere mai
leggibile alla stazione mobile la chiave Ki [134][135].
6.2.2
WiFi
La protezione della connessione WiFi è implementata usando 3 diversi protocolli: WEP, WPA,
WPA2. Il primo attacco per WEP (Wired Equivalent Privacy) è stato scoperto nel 2001 [136].
In seguito altri attacchi sono stati formulati, sfruttando diverse tecniche nel 2004, 2005, 2007 e
2010 [137]. Più recentemente, anche su WPA sono state scoperte vulnerabilità nel 2008 [138],
2009 e 2010 [137]. Attualmente WPA2 è il protocollo più sicuro ed utilizzato.
WPA2 prevede sia l’autenticazione che la cifratura. L’autenticazione può avvenire in due modi:
116
http://pages.cpsc.ucalgary.ca/
103
• WPA Personal : detto anche WPA-PSK (Pre Shared Key), è progettato per abitazioni e
piccole reti. Non necessita di un server di autenticazione. Viene impostata una password
nell’Access Point (ad esempio il router WiFi) e la stessa va digitata sul dispositivo mobile
al momento della connessione.
• WAP Enterprise: dello anche WPA-802.1X, è progettato per reti aziendali e necessita di
un server di autenticazione RADIUS. Il setup è più complicato, ma fornisce maggiore sicurezza (ad esempio protezione contro attacchi dizionario). Utilizzando l’Extensible Authentication Protocol (EAP), consente di utilizzare per l’autenticazione token cards (Smart
Cards), Kerberos, one-time passwords, certificati e autenticazione con chiave pubblica.
L’autenticazione si articola in due fasi:
Prima fase: L’utilizzo della modalità WPA Personal o WPA Enterprise determina il modo
in cui viene eseguita la prima fase della procedura di autenticazione, in cui stazione mobile e
punto di accesso devono arrivare a conoscere una stessa Pairwise Mater Key (PMK) di 256 bit.
In WPA Personal, la PMK è calcolata da entrambe le parti applicando la funzione PBKDF2
alla password della connessione: l’SSID è utilizzato come sale e sono eseguite 4096 iterazioni di
HMAC-SHA1.
In WPA Enterprise, la PMK è già nota alla stazione mobile (in modi diversi a seconda del
metodo di autenticazione utilizzato) e viene resa nota al punto di accesso in seguito all’autenticazione eseguita col server RADIUS. A differenza del caso WPA Personal, la PMK è diversa
per ogni utente con accesso alla rete.
Al termine della procedura sotto illustrata, nel caso WPA Enterprise si avrà autenticazione
dello specifico utente con accesso alla rete, mentre in WPA Personal si ha autenticazione di un
generico utente a conoscenza della password della rete.
Seconda fase: La seconda fase della procedura di autenticazione prevede che stazione mobile
e punto di accesso provino l’uno all’altra di essere a conoscenza della PMK. Ciò avviene con
un meccanismo di four-way handshake descritto nel protocollo IEEE 802.11i [139]. Poiché
la PMK è progettata per durare per l’intera sessione e deve essere esposta il meno possibile,
vengono generate chiavi temporanee (Pairwise Transient Key, PTK) per cifrare il traffico dati
tra stazione mobile e punto di accesso. Tali chiavi, di 128 bit, sono generate sempre nel corso
del four-way handshake e la procedura è ripetuta periodicamente allo scadere di un timeout.
Le PTK sono utilizzate per cifrare la comunicazione tra stazione mobile e punto di accesso, che
avviene secondo il protocollo CCMP basato su AES in modalità CCM (che combina CTR per
la confidenzialità e CBC-MAC per autenticazione e integrità).
WPA supplicant wpa supplicant implementa e gestisce l’autenticazione, l’associazione e la
negoziazione delle chiavi del driver WLAN con un Autenticatore WPA, o l’autenticazione EAP
con un server di autenticazione. wpa supplicant è un demone di sistema che viene eseguito in
background ed è il componente designato per il controllo della connessione wireless [140].
Di seguito i principali passaggi utilizzati per associare un dispositivo wifi ad un Access Point
usando WPA2 [141]:
1. wpa supplicant richiede al driver del kernel di eseguire una scansione per individuare le
vicine Base Station (BSS).
104
2. wpa supplicant richiede al driver kernel di associarsi con la BSS scelta.
3. Se WPA-EAP: il supplicant IEEE 802.1X completa l’autenticazione EAP con il server di
autenticazione ed in seguito riceve una master session key.
4. Se WPA-PSK: wpa supplicant usa la Pre Shared Key come master session key.
5. wpa supplicant completa il WPA 4-Way Handshake con l’Access Point.
6. wpa supplicant configura le chiavi di cifratura per il traffico unicast e broadcast.
7. Normali pacchetti dati possono essere trasmessi e ricevuti.
Per la connessione ad una rete wireless usando la modalità WPA Personal è necessario compilare
il file configurazione /etc/wpa supplicant.conf con le informazioni sulla rete, come nell’esempio
sotto riportato. Nel caso in cui siano a disposizione dei tool grafici, la compilazione del file
avviene in modo automatico. È interessante notare come il valore della password, psk, venga
salvato in chiaro.
network={
s s i d=”home”
s c a n s s i d =1
key mgmt=WPA−PSK
psk=” v e r y s e c r e t p a s s p h r a s e ”
}
Se nel campo PSK la password viene scritta in caratteri ASCII tra apici, al momento della connessione il modulo wpa supplicant si occupa di generare la chiave PMK (Pairwise Master Key)
secondo l’algoritmo spiegato nel paragrafo precedente, ottenendo una chiave di 256 bit. Alternativamente, per evitare di memorizzare la password PSK ASCII in chiaro [142], è possibile
utilizzare il programma wpa passphrase per generare la chiave PMK e memorizzare direttamente quest’ultima. È importante rimarcare come questa non sia una misura di sicurezza per
la protezione della password della rete wifi: il valore della chiave PMK calcolato viene sempre
salvato in chiaro. Copiando questo valore nel file di configurazione /etc/wpa supplicant.conf è
sufficiente per connettersi alla rete wifi. Resta comunque una misura di sicurezza interessante
nel caso in cui la stessa password di accesso alla rete wifi sia utilizzata anche in altri contesti,
dunque si previene di salvarla in chiaro.
6.3
Address Space Layout Randomization
ASLR è una tecnica di sicurezza che impiega il posizionamento casuale di aree di memoria
chiave all’interno dello spazio di indirizzamento di un processo. Introducendo un ordinamento
casuale nel layout di memoria di un programma, ASLR ne diminuisce la predicibilità e riduce
la possibilità che un tentativo di exploit abbia successo [121].
Nelle comuni tecniche di exploit, per eseguire codice malevole, viene sovrascritto l’indirizzo
di ritorno di una funzione utilizzando dei puntatori hard-coded. L’utilizzo di ASLR riduce la
predicibilità degli indirizzi di memoria, perché lo spazio di indirizzamento viene randomizzato
ad ogni esecuzione del programma. La probabilità che un tentativo di exploit mandi in crash
il processo è alta. Sebbene un attacco di questo tipo potrebbe essere ancora utilizzato per un
denial of service, la sua semplice individuazione lo rende non efficace.
In un processo, le principali aree di memoria sono:
105
• Stack: contiene i parametri e le variabili locali.
• Heap: contiene le strutture dati allocate dinamicamente.
• BSS: contiene le variabili non inizializzate sia statiche locali, che globali.
• Data: contiene le variabili inizializzate globali e quelle statiche locali.
• Text: contiene il codice del programma.
Utilizzando ASLR, il loro posizionamento varia ad ogni esecuzione.
Originariamente ASLR era parte del progetto Page Exec (PaX) ed è disponibile dalla versione
2.6.12 del Kernel Linux, pubblicata nel giugno 2005.
ASLR non è una soluzione perfetta[143]: la sicurezza offerta è basata su diversi fattori che
includono il grado di predicibilità del layout di memoria di un programma, quando è tollerante
una tecnica di exploit al layout di memoria ed il numero di tentativi un attaccante è in grado di
eseguire. La sua efficacia dipende anche dal numero di bit dell’indirizzo di memoria utilizzati
nella randomizzazione: ogni bit in più duplica il numero dei possibili layout di memoria. L’utilizzo di un’architettura a 64 bit è notevolmente più efficace: la maggior parte degli attacchi
brute-force su un’architettura a 32 bit non avranno successo in una a 64 bit. Uno degli svantaggi dell’utilizzo di ASLR è quello di rendere l’operazione di analisi dei crash e di debug più
complicata. Per questo motivo è quasi sempre possibile disattivarlo.
6.4
Data Execution Prevention
DEP è una tecnica di mitigazione degli exploit che rende l’area di memoria in cui vengono
salvati i dati non eseguibile, prevenendo l’esecuzione di codice arbitrario [144]. L’architettura
dei calcolatori moderni permette a codice e dati di coesistere nella stessa regione di memoria
contemporaneamente: i programmi possono essere più facilmente caricati da disco e gli aggiornamenti software sono più semplici [123]. Per implementare DEP, i dispositivi moderni usano
una combinazione di tecniche hardware e software. Entrambi i processori ARM e x86 prevedono la non esecuzione delle aree di memoria riservate ai dati, ma ciascuna piattaforma utilizza
tecnologie leggermente diverse, che devono essere supportate a livello Kernel. Se un programma tenta di eseguire un’area di memoria marcata come non eseguibile, a livello di processore
viene generato un segnale di fault. In seguito, viene gestito dal kernel del sistema operativo e
conseguentemente inviato un segnale al processo, causandone la terminazione.
6.5
Modelli per il controllo degli accessi
I modelli di controllo per gli accessi forniscono la protezione dell’informazione da accessi non
autorizzati e garantiscono l’integrità delle politiche di sicurezza che stabiliscono le regole di
accesso e condivisione delle informazioni all’interno di un sistema [145].
I modelli di seguito brevemente trattati sono il “Discretionary access control” ed il “Mandatory
Access Control”,
106
6.5.1
Discretionary access control
DAC è un modello di controllo degli accessi che permette all’utente di decidere, in modo
discrezionario (“Discretionary”), i diritti di accesso agli oggetti di sua proprietà [145].
Storicamente, i sistemi operativi derivati da Unix usano il modello DAC [146]. L’implementazione si basa sul concetto di proprietà e permessi di accesso (lettura, scrittura, esecuzione). Ad
ogni oggetto di sistema, come file e cartelle, viene associato un utente ed un gruppo proprietari
ed i permessi di accesso per l’utente ed il gruppo proprietari e per tutti gli altri.
La flessibilità del modello, ma anche la sua principale debolezza, è data dalla possibilità per
gli utenti di cambiare i permessi dei propri file. Ad esempio, un utente potrebbe dare accesso
in lettura, scrittura ed esecuzione a chiunque alla propria directory home. In seguito, nulla
potrebbe prevenire che altri utenti o processi accedano al contenuto della cartella in questione.
Le scelte sul controllo degli accessi vengono prese dall’utente individuale, indipendentemente
dalla presenza di una politica globale, introducendo possibili inconsistenze [145]. Inoltre, il modello è fortemente insicuro in presenza di programmi malevoli: un malware potrebbe cambiare
le politiche DAC di accesso ad alcuni file, per conto dell’utente che lo esegue.
6.5.2
Mandatory Access Control
MAC è un modello di controllo degli accessi in cui una politica di sistema decreta (“Mandatory”)
“a chi è consentito avere accesso a ciascun oggetto”. Gli utenti individuali non possono alterare
le scelte.
In un sistema operativo che implementa il modello “Mandatory Access Control” la politica di
accesso è stabilita da un amministratore [146]. Anche se venissero cambiate le impostazioni
DAC nella cartella “home” di un utente, se esiste una politica che previene che altri utenti o
processi vi accedano, prevale quest’ultima. Le politiche MAC possono essere definite in modo
molto dettagliato, per controllare ad esempio l’accesso tra utenti, file, direttori, memoria, socket
udp e tcp, ecc.
6.6
LXC / Linux Containers
LXC è una soluzione di virtualizzazione leggera, nota anche come “virtualizzazione a livello
di sistema operativo” [147]. L’unità virtualizzata è il container, che fornisce l’isolamento del
processo e delle risorse: permette di eseguire in modo sicuro più applicazioni su un singolo
sistema senza il rischio che queste interferiscano tra loro. Se la sicurezza di un container venisse
compromessa, gli altri container rimarrebbero non affetti.
LXC è leggero e “resource-friendly” [148]: consente di eseguire istanze multiple di un sistema
operativo e delle relative applicazioni su un singolo host, senza avere overhead in termini di
CPU e memoria. Risulta essere più veloce rispetto all’alternativa virtualizzazione completa,
avendo un footprint medio fino a dieci volte inferiore [149].
Un container è un processo in userspace. Per la creazione viene sfruttato il supporto del kernel,
utilizzando sia i namespace, che i control groups. I primi vengono impiegati per l’isolamento
delle risorse, i secondi per la loro limitazione ed accounting. Ad esempio, i container possono
essere configurati per usare una differente quantità di risorse in termini di CPU, memoria e
I/O. Tutti i container condividono lo stesso kernel del sistema operativo host.
107
Riferimenti bibliografici
[1] Francesco Russo. I dispositivi mobili connessi superano la popolazione mondiale. http:
//www.agoravox.it/I-dispositivi-mobili-connessi.html.
[2] Antonio Dini. Gli smartphone sono 1,2 miliardi, saranno 4 nel 2018. boom traffico dati,
il rapporto con la voce è 8 a 1. http://www.ilsole24ore.com/art/tecnologie/201305-31/smartphone-sono-miliardi-saranno-185531.shtml.
[3] Infonetics Research. Infonetics projects mobile device security software market to reach
3.4 billion in 2018. http://www.infonetics.com/pr/2014/2H13-Mobile-SecurityClient-Software-Market-Highlights.asp.
[4] Adrienne Porter Felt, Matthew Finifter, Erika Chin, Steve Hanna, and David Wagner.
A survey of mobile malware in the wild. In Proceedings of the 1st ACM workshop on
Security and privacy in smartphones and mobile devices, pages 3–14. ACM, 2011.
[5] Philip Marquardt, Arunabh Verma, Henry Carter, and Patrick Traynor. (sp) iphone:
decoding vibrations from nearby keyboards using mobile phone accelerometers. In Proceedings of the 18th ACM conference on Computer and communications security, pages
551–562. ACM, 2011.
[6] A cryptolocker for android?
android/.
https://blog.kaspersky.com/new-ransomware-for-
[7] Mariantonietta La Polla, Fabio Martinelli, and Daniele Sgandurra. A survey on security
for mobile devices. Communications Surveys & Tutorials, IEEE, 15(1):446–471, 2013.
[8] Siemens s55 sms send prompt bypass weakness. http://marc.info/?l=secunia-secadv&m=108315642409515.
[9] Intrusion and protection of mobile devices. http://www.fortiguard.com/files/
Intrusion_and_Protection_of_Mobile_Devices.pdf.
[10] Bluetooth-worm:symbos/cabir. https://www.f-secure.com/v-descs/cabir.shtml.
[11] Peter Szor. The art of computer virus research and defense. Pearson Education, 2005.
[12] Fakeav holds android phones for ransom. http://www.symantec.com/connect/blogs/
fakeav-holds-android-phones-ransom.
[13] Simplocker:
First confirmed file-encrypting ransomware for android.
//www.symantec.com/connect/blogs/simplocker-first-confirmed-fileencrypting-ransomware-android.
http:
[14] A detailed analysis of the first locking and file encrypting ransomware for android.
https://hackmag.com/malware/a-detailed-analysis-of-the-first-lockingand-file-encrypting-ransomware-for-android/.
[15] Understanding crypto-ransomware. http://www.bromium.com/sites/default/files/
bromium-report-ransomware.pdf.
[16] Cryptolocker e altri ransomware: come decodificare i file. http://www.ilsoftware.
it/articoli.asp?tag=Cryptolocker-e-altri-ransomware-come-decodificare-ifile_12149.
108
[17] Faq ubuntu touch. https://wiki.ubuntu.com/Touch/FAQ.
[18] Ricardo Salveti.
O2qEAbuk_i8.
Ubuntu touch internals.
https://www.youtube.com/watch?v=
[19] Container architecture. https://wiki.ubuntu.com/Touch/ContainerArchitecture.
[20] Unity8. https://wiki.ubuntu.com/UnityNextSpec.
[21] Qml. http://en.wikipedia.org/wiki/QML.
[22] Qt. http://en.wikipedia.org/wiki/Qt_%28software%29.
[23] Rex Tsai. Ubuntu phone engineering.
[24] Linux security modules. https://en.wikipedia.org/wiki/Linux_Security_Modules.
[25] Crispin Cowan. Securing linux application with apparmor. https://www.youtube.com/
watch?v=mp23AO8qtE4.
[26] Overview of linux capabilities. http://manpages.ubuntu.com/manpages/gutsy/man7/
capabilities.7.html.
[27] Se-linux guide.
https://access.redhat.com/documentation/en-US/Red_Hat_
Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/.
[28] Marc Deslauriers. Ubuntu touch and user privacy. http://mdeslaur.blogspot.ch/
2013/12/ubuntu-touch-and-user-privacy.html.
[29] Content hub. https://design.ubuntu.com/apps/patterns/content-hub.
[30] Content hub guide.
https://developer.ubuntu.com/en/apps/platform/guides/
content-hub-guide/.
[31] Click package signing. https://wiki.ubuntu.com/SecurityTeam/Specifications/
ClickPackageSigning.
[32] Application confinement. https://wiki.ubuntu.com/SecurityTeam/Specifications/
ApplicationConfinement.
[33] Mike Halcrow. ecryptfs: a stacked cryptographic filesystem. http://www.linuxjournal.
com/article/9400.
[34] Disk encryption. https://wiki.archlinux.org/index.php/Disk_encryption.
[35] ecryptfs. https://wiki.archlinux.org/index.php/ECryptfs.
[36] How does apparmor do environment scrubbing.
http://stackoverflow.com/
questions/5835664/how-does-apparmor-do-environment-scrubbing.
[37] Prey project. https://preyproject.com/.
[38] Cyanogenmod. http://en.wikipedia.org/wiki/CyanogenMod.
[39] About cyanogenmod. http://wiki.cyanogenmod.org/w/About.
[40] About cyanogenmod. http://www.cyanogenmod.org/about.
109
[41] Rooting (android os). http://en.wikipedia.org/wiki/Rooting_%28Android_OS%29.
[42] Android Wiki. Content providers.
security/index.html.
https://source.android.com/devices/tech/
[43] Cyanogenmod privacy guard updated and merged with cm10.2.
http:
//androidcommunity.com/cyanogenmod-privacy-guard-updated-and-mergedwith-cm10-2-20130925/.
[44] Ryan Whitwam. App ops was never meant for end users, used for internal testing and debugging only. http://www.androidpolice.com/2013/12/11/googler-app-ops-wasnever-meant-for-end-users-used-for-internal-testing-and-debugging-only/.
[45] Protecting your privacy: App ops, privacy guard, and xprivacy. http://www.xdadevelopers.com/protecting-your-privacy-app-ops-privacy-guard-andxprivacy/.
[46] Jonathan Feist. Superuser settings to be handled in cyanogenmod 12 through privacy
guard. http://androidcommunity.com/cyanogenmod-privacy-guard-updated-andmerged-with-cm10-2-20130925/.
[47] Cyanogenmod account. http://www.cyanogenmod.org/blog/cyanogenmod-account.
[48] Scott Brown.
Cyanogenmod breaks new ground on mobile privacy.
http:
//www.scottbrownconsulting.com/2013/08/cyanogenmod-breaks-new-groundon-mobile-privacy/.
[49] Dispositivo a blocchi. https://it.wikipedia.org/wiki/Dispositivo_a_blocchi.
[50] Dm-crypt. https://en.wikipedia.org/wiki/Dm-crypt.
[51] Disk encryption theory. https://en.wikipedia.org/wiki/Disk_encryption_theory#
Encrypted_salt-sector_initialization_vector_.28ESSIV.29.
[52] Encryption. https://source.android.com/devices/tech/security/encryption/.
[53] Olga Gadyatskaya, Fabio Massacci, and Yury Zhauniarovich. Emerging mobile platforms:
Firefox os and tizen.
[54] Irfan Asrar. Attack surface analysis of the tizen os.
[55] Samsung Electronics Seokjae Jeong. Tizen overview and architecture. https://events.
linuxfoundation.org/images/stories/pdf/lceu2012_haitzler.pdf.
[56] Kirill Kruchinkin.
Practical approach to creating hybrid/native tizen apps.
http://www.slideshare.net/SymphonyTeleca/practical-approach-to-creatinghybridnative-tizen-apps.
[57] Multi-user architecture. https://wiki.tizen.org/wiki/Multi-user_Architecture.
[58] Smart development bridge.
https://developer.tizen.org/documentation/
articles/smart-development-bridge.
[59] Security/tizen 2.x debugging environment. https://wiki.tizen.org/wiki/Security/
Tizen_2.X_Debugging_Environment.
110
[60] Tizen architecture overview. https://www.tizen.org/sites/default/files/tizenarchitecture-linuxcollab.pdf.
[61] Byung Woan Kim.
Overview of the tizen native application framework.
http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013Overview_of_the_Tizen_Native_Application_Framework.pdf.
[62] Web runtime.
https://developer.tizen.org/dev-guide/2.2.0/org.tizen.web.
appprogramming/html/basics_tizen_programming/web_runtime.htm.
[63] Ming Jin.
Tizen web runtime.
https://download.tizen.org/misc/media/
conference2012/tuesday/ballroom-a/2012-05-08_1515-1555-tizen_web_runtime.
pdf.
[64] Nathan Willis. A look at the crosswalk web runtime. http://lwn.net/Articles/
618152/.
[65] Security/tizen 3.x overview.
Overview.
https://wiki.tizen.org/wiki/Security/Tizen_3.X_
[66] Security/tizen 2.x overview.
Overview.
https://wiki.tizen.org/wiki/Security/Tizen_2.X_
[67] Jake Edge. Smack for simplified access control. http://lwn.net/Articles/244531/.
[68] Casey Schaufler. Smack and the application ecosystem. http://linuxplumbersconf.
org/2009/slides/Casey-SmackPlumbers2010.pdf.
[69] Security/tizen 2.x libprivilege-control.
Tizen_2.X_libprivilege-control.
https://wiki.tizen.org/wiki/Security/
[70] Casey Schaufler. The smack project. http://www.schaufler-ca.com.
[71] Security:smack. https://wiki.tizen.org/wiki/Security:Smack.
[72] Security/tizen 2.x smack.
Smack.
https://wiki.tizen.org/wiki/Security/Tizen_2.X_
[73] Security/tizen 2.x user id & group id.
Tizen_2.X_User_ID_%26_group_ID.
https://wiki.tizen.org/wiki/Security/
[74] Multi-user architecture. https://wiki.tizen.org/wiki/Multi-user_Architecture.
[75] Nathan Willis. Talking smack for tizen security. https://lwn.net/Articles/552787/.
[76] Security:smackthreedomainmodel.
SmackThreeDomainModel.
https://wiki.tizen.org/wiki/Security:
[77] Security:cynara. https://wiki.tizen.org/wiki/Security:Cynara.
[78] Nathan Willis. Tizen’s new access-control broker cynara. http://lwn.net/Articles/
602060/.
[79] Security:cynara:comparisonwithothersolutions.
https://wiki.tizen.org/wiki/
Security:Cynara:ComparisonWithOtherSolutions.
111
[80] Franziska Roesner, Tadayoshi Kohno, Alexander Moshchuk, Bryan Parno, Helen J Wang,
and Crispin Cowan. User-driven access control: Rethinking permission granting in modern operating systems. In Security and privacy (SP), 2012 IEEE Symposium on, pages
224–238. IEEE, 2012.
[81] Tizen 2.2.1 release notes. https://developer.tizen.org/tizen-sdk.
[82] Exception handling for privacy-sensitive apis. https://developer.tizen.org/devguide/2.2.1/org.tizen.gettingstarted/html/tizen_overview/exception_
handling.htm.
[83] Security/webapps and smack.
and_Smack.
https://wiki.tizen.org/wiki/Security/WebApps_
[84] Security/tizen 2.x privileges. https://wiki.tizen.org/wiki/Security/Tizen_2.X_
Privileges.
[85] Security/tizen 2.x architecture. https://wiki.tizen.org/wiki/Security/Tizen_2.X_
Architecture.
[86] HoJun Jaygarl, Cheng Luo, YoonSoo Kim, Eunyoung Choi, Kevin Bradwick, et al.
Professional Tizen Application Development. John Wiley & Sons, 2014.
[87] Security/tizen 2.x libprivilege-control.
Tizen_2.X_libprivilege-control.
https://wiki.tizen.org/wiki/Security/
[88] Security/tizen 2.x smack-privilege-config. https://wiki.tizen.org/wiki/Security/
Tizen_2.X_smack-privilege-config.
[89] Security/tizen 3.x security manager. https://wiki.tizen.org/wiki/Security/Tizen_
3.X_Security_Manager.
[90] Mailing list for discussions about the development of tizen itself. http://comments.
gmane.org/gmane.comp.handhelds.tizen.devel/17.
[91] Security:vasum. https://wiki.tizen.org/wiki/Security:Vasum.
[92] Dean Pierce. Breaking same-origin for fun and profit. https://download.tizen.
org/misc/media/conference2012/tuesday/seacliff/2012-05-08-1600-1640breaking_same-origin_for_fun_and_profit.pdf.
[93] Ltd. Hyeokgon Ryu, Infraware Technology. Publishing to tizen using the automated
conversion/repackaging of existing android apps. http://cdn.download.tizen.org/
misc/media/conference2013/slides/TDC2013-Publishing_to_TIZEN_Using_the_
Automated_Conversion-Repackaging_of_Existing_Android_Apps.pdf.
[94] http://pag.polarismobile.com. http://pag.polarismobile.com/login.
[95] Conversion of existing android apps to tizen apps using polaris app generator
(pag). http://www.whatistizen.com/conversion-of-existing-android-apps-totizen-apps-using-polaris-app-generator-pag/.
[96] James Forshaw. Webgl-a new dimension for browser exploitation. Online: http://www.
contextis. com/resources/blog/webgl, 2011.
112
[97] James Forshaw, Paul Stone, and Michael Jordon. Webgl-more webgl security flaws. Context Blog. URL: http://www. contextis. com/research/blog/webgl2/-Retrieved April, 10,
2012.
[98] Webgl considered harmful. http://blogs.technet.com/b/srd/archive/2011/06/16/
webgl-considered-harmful.aspx.
[99] Technical explanation of the myspace worm. http://namb.la/popular/tech.html.
[100] Dave Wichers. Owasp top-10 2013. OWASP Foundation, February, 2013.
[101] Guilherme Iscaro. A simple sms reader. https://giscaro.wordpress.com/2012/04/
10/a-simple-sms-reader/.
[102] Tizen. http://it.wikipedia.org/wiki/Tizen.
[103] Tizen validation guidelines. https://developer.tizen.org/sites/default/files/
documentation/tizen_validation_guide_ver_1.4_140529.pdf.
[104] Tizen Validation Team Taegu Lee.
Tizen application validation.
http:
//download.tizen.org/misc/media/conference2014/slides/tdc2014-tizenapplication-validation.pdf.
[105] Jon Oberheide and Charlie Miller. Dissecting the android bouncer. SummerCon2012,
New York, 2012.
[106] How to access the tizen store in samsung z1 – using vpn + laptop in windows. http://www.downloadtizenapps.com/2015/02/tutorial-how-to-access-thetizen-store-in-samsung-z1-using-vpn-laptop-in-windows.html.
[107] App installer workshop status. http://permalink.gmane.org/gmane.comp.handhelds.
tizen.devel/5056.
[108] wgt package source code encryption. https://developer.tizen.org/fr/forums/webapplication-development/wgt-package-source-code-encryption?langswitch=fr.
[109] Web application protection. https://tizendevelopers.wordpress.com/2013/09/30/
web-application-protection/.
[110] Key manager.
https://developer.tizen.org/documentation/guides/nativeapplication/security/key-manager.
[111] Tizen 2.x secure-storage.
Secure-storage.
https://wiki.tizen.org/wiki/Security/Tizen_2.X_
[112] Inc. Sreenu Pillutla, Director of Engg. McAfee.
Content security framework.
http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013Content_Security_Framework.pdf.
[113] Collaboration summit 2013 - tizen content security framework. https://www.youtube.
com/watch?v=GtiAQOo4beg.
[114] Nathan Willis. Tizen content scanning and app obfuscation.
Articles/553676/.
https://lwn.net/
[115] Tizen’s content security framework. https://developer.tizen.org/forums/generalsupport/tizens-content-security-framework.
113
[116] Security/tizen 2.x csr-framework. https://wiki.tizen.org/wiki/Security/Tizen_2.
X_csr-framework.
[117] Porting guide/connectivity.
Connectivity.
https://wiki.tizen.org/wiki/Porting_Guide/
[118] http://t3746.handhelds-tizen-general.pdatalk.info/in-wich-file-is-wlanpassword-saved-t3746.html.
[119] Security/tizen 2.x ca-certificates. https://wiki.tizen.org/wiki/Security/Tizen_2.
X_ca-certificates.
[120] Security/tizen 2.x cert-svc-ui. https://wiki.tizen.org/wiki/Security/Tizen_2.X_
cert-svc-ui.
[121] Ollie Whitehouse. An analysis of address space layout randomization on windows vista.
Symantec advanced threat research, pages 1–14, 2007.
[122] Hristo Bojinov, Dan Boneh, Rich Cannings, and Iliyan Malchev. Address space randomization for mobile devices. In Proceedings of the fourth ACM conference on Wireless
network security, pages 127–138. ACM, 2011.
[123] Joshua J Drake, Zach Lanier, Collin Mulliner, Pau Oliva Fora, Stephen A Ridley, and
Georg Wicherski. Android Hacker’s Handbook. John Wiley & Sons, 2014.
[124] Robert C Seacord. Secure Coding in C and C++. Pearson Education, 2005.
[125] Tizen::shell::lockmanager class reference.
https://developer.tizen.org/devguide/2.2.0/org.tizen.native.apireference/classTizen_1_1Shell_1_
1LockManager.html#a59b473817e9dda49128f14ff3b1b19f5.
[126] Lock screen. https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.
appprogramming/html/guide/shell/lock_screen.htm.
[127] Types of screen lock options in tizen based smartphones. http://www.samsung.com/in/
support/skp/faq/1073648.
[128] Vulnerability summary for cve-2012-6459.
detail?vulnId=CVE-2012-6459.
http://web.nvd.nist.gov/view/vuln/
[129] Bugs tizen: still see bluetooth service even offline mode turned on. https://bugs.tizen.
org/jira/browse/TIVI-211.
[130] AJIN ABRAHAM. Hacking tizen the os of everything. http://www.slideshare.net/
ajin25/hacking-tizen-the-os-everything-nullcon-goa-2015.
[131] Corona sdk. https://coronalabs.com/.
[132] Ubuntu touch tablet. http://www.ubuntu.com/tablet.
[133] Cold boot attack. https://en.wikipedia.org/wiki/Cold_boot_attack.
[134] Gsm authentication. http://pages.cpsc.ucalgary.ca/~szrrizvi/cpsc329/t2.html.
[135] How authentication works in gsm.
http://www.teletopix.org/gsm/howauthentication-center-auc-works-in-gsm/.
114
[136] Scott Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the key scheduling algorithm
of rc4. In Selected areas in cryptography, pages 1–24. Springer, 2001.
[137] Caneill Matthieu and Gills Jean-Loup. Attacks against the wifi protocols wep and wpa.
[138] Erik Tews and Martin Beck. Practical attacks against wep and wpa. In Proceedings of
the second ACM conference on Wireless network security, pages 79–86. ACM, 2009.
[139] Wikipedia - ieee 802.11i. https://en.wikipedia.org/wiki/IEEE_802.11i-2004.
https://www.freebsd.org/cgi/man.cgi?query=wpa_
[140] Wpa supplicant.conf(5).
supplicant.conf&sektion=5.
[141] wpa supplicant(8) - linux man page. http://linux.die.net/man/8/wpa_supplicant.
http://superuser.com/
[142] wpa supplicant passphrase, can it be normal password?
questions/679956/wpa-supplicant-passphrase-can-it-be-normal-password.
[143] Tilo Muller. Aslr smack & laugh reference-seminar on advanced exploitation techniques.
RWTH Aachen, Germany-Chair of Computer Science, 4, 2008.
[144] Vinay Katoch Vulnerability Research Specialist. Whitepaper on bypassing aslr/dep.
[145] Ryan Ausanka-Crues. Methods for access control: advances and limitations. Harvey
Mudd College, 301, 2001.
[146] Se linux for mere mortal.
http://people.redhat.com/tcameron/summit2010/
selinux/SELinuxMereMortals.pdf.
[147] Christoph Mitasch. Lightweight virtualization. https://www.thomas-krenn.com/de/
wikiDE/images/c/cf/20121106-Lighweight_Virtualization_LXC_Best_Practices.
pdf.
[148] Linux containers (lxc).
features-1405324.pdf.
http://www.oracle.com/us/technologies/linux/lxc-
[149] Jerome Petazzoni.
Lightweight virtualization lxc container.
https://www.
socallinuxexpo.org/scale11x-supporting/default/files/presentations/
Jerome-Scale11x%20LXC%20Talk.pdf.
115