June 2015 - GitHub · 1 Introduzione 1.1 Il mercato dei dispositivi mobili Il vertiginoso sviluppo...

Mobile OSs analysisReport 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 Modalita dell’analisi di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.1 Poca integrazione tra S.O. mobili e fissi . . . . . . . . . . . . . . . . . . . 18

2.2.2 Convergenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 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.5.1 La necessita 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

2.6 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 Memorizzazione dati critici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.7.1 GNOME Keyring e AppArmor . . . . . . . . . . . . . . . . . . . . . . . 33

2.7.2 Credenziali web: Ubuntu online accounts . . . . . . . . . . . . . . . . . . 33

2.8 Cifratura dati utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.8.1 Introduzione a eCryptfs . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.8.2 Funzionamento di eCryptfs . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.9 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 Vulnerabilita note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.12 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 CyanogenMod 40


3.2 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.1 Storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.2 Differenze con Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.3 Distribuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.4 Device Rooted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.8 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3

4 Tizen 51


4.2 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

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

4.3 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

4.4 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


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 Criticita progettuali ed implementative delle applicazioni . . . . . . . . . . . . . 74

4.6.1 Conversione automatica della applicazioni . . . . . . . . . . . . . . . . . 74

4.6.2 WebGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.6.3 XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.7 Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4

4.7.1 Il processo di revisione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.7.2 Connessione alla Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.7.3 Store non ufficiali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.8 Cifratura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.8.1 Cifratura applicazioni Web . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.9 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.11 Vulnerabilita 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 GNOME Keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.2 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.5.1 Discretionary access control . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.5.2 Mandatory Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.6 LXC / Linux Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5

1 Introduzione

1.1 Il mercato dei dispositivi mobili

Il vertiginoso sviluppo tecnologico che ha caratterizzato l’ultimo ventennio ha portato diverseinnovazioni, permettendo di lanciare sul mercato numerosi dispositivi innovativi. I progressisulla “portabilita” della tecnologia hanno giocato un ruolo essenziale: sono nati nuovi dispositivitascabili che hanno permesso di soddisfare la crescente necessita di archiviazione di dati e diconnettivita in movimento. Il mercato dei dispositivi mobili, ha reso “portabili” gran partedelle funzionalita fino a quel momento ristrette ai soli computer desktop, introducendo i nuovismartphone, tablet e computer portatili, tutti dotati di caratteristiche necessarie per un costanteutilizzo al di fuori dei tradizionali confini aziendali e domestici.

Considerando i soli dispositivi in grado di connettersi ad internet, il loro numero ha recentementesuperato quello della popolazione mondiale: i dati [1] stimano 7.3 miliardi di dispositivi contro7.2 miliardi di persone. Di questi piu di 1.2 miliardi sono telefoni cellulari e il loro numero edestinato a crescere, raggiungendo i 4 miliardi nel 2018 [2], con un forte sviluppo del mercatoasiatico, soprattutto in Cina ed India.

Sebbene il termine dispositivo mobile si riferisca ad un insieme di dispositivi molto vasto, cometecnologie wearable, smartphone, fotocamere ed altri, nel corso del report sara utilizzato perindicare 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 leapplicazioni e tutte le altre funzionalita sono offerte da un sistema operativo. L’importanzaacquisita negli ultimi anni dai dispositivi mobile rende necessario un’approfondita analisi dellesoluzioni di sicurezza adottate dai diversi sistemi. Nelle successive sezioni saranno analizzatele principali differenze che caratterizzano il mondo mobile dal tradizionale desktop e le relativeimplicazioni di sicurezza. Saranno anche introdotti i principali obiettivi e vettori di attacco, lecui contromisure verrano successivamente analizzate per ciascun sistema operativo trattato.

1.2 Il problema della sicurezza

L’avanzamento tecnologico garantisce ai dispositivi mobili una capacita computazionale sempremaggiore. Da un lato, combinata con veloci interfacce di connessione, ha reso i dispositivimobili bersagli di attacco appetibili per l’utilizzo anche in contesti malevoli, come all’interno dibotnet. Dall’altro, una maggior capacita computazionale, unita alle caratteristiche di “porta-bilita” e semplicita d’uso, ha contribuito ad offrire maggiori funzionalita agli utenti. Alcune diqueste sono operazioni sensibili per la sicurezza e privacy degli utilizzatori. Ad esempio, moltidispositivi mobile permettono di eseguire operazioni delicate quali l’esecuzione di movimentibancari o la gestione di servizi a pagamento. La loro diffusione ha ampliato enormemente ilpanorama degli utilizzatori, estesosi a quasi tutte le fasce di eta. Oltre ad un incremento diutilizzo, si e assistito anche ad un aumento della fiducia nei download di contenuti provenientida autori sconosciuti.

A livello applicativo, la semplificazione della procedura di sviluppo, anche tramite l’introdu-zione di SDK evoluti, ha favorito la crescita delle applicazioni disponibili. Nel primo trimestredel 2014, i due maggiori store distributori di applicazioni (AppStore e GooglePlay) hanno to-talizzato globalmente circa 250 milioni di download. La ricerca di malware nel volume delleapplicazioni esistenti, e difficile.

La sicurezza in ambito mobile e un problema importante, che richiede di essere adeguatamenteaffrontato: 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 e quello riguardante la crescita di minacce, in particolare quellefinalizzate all’estorsione di denaro, come mostrato in Figura 1.

1.2.1 Differenze tra sicurezza su mobile e su fisso

La diversita tra i dispositivi mobili ed i calcolatori tradizionali rende difficile la semplice mi-grazione delle soluzioni di sicurezza gia disponibili, richiedendone la progettazione di nuove. Diseguito sono elencate le differenze tra il mondo mobile e fisso che maggiormente influiscono sulcampo della sicurezza.

• Mobilita: i dispositivi mobili nascono per poter essere sempre trasportati con se. Selasciati incustoditi, sono soggetti a furto o ad accesso non autorizzato: e necessario averea disposizione nuovi sistemi per la protezione dell’accesso fisico.

• Connettivita: smartphone e tablet supportano varie tecnologie di comunicazione (GSM,3G/4G, Wi-Fi, Bluetooth, NFC), tutte rappresentano canali per possibili attacchi. Seb-bene alcuni siano presenti anche sui sistemi fissi, nel caso dei dispositivi mobili sonoindubbiamente molto piu utilizzati, anche quando non necessario. Un esempio sono ilBluetooth ed il Wi-Fi, che vengono spesso lasciati attivi per comodita.

• Scheda SIM: e necessaria per il funzionamento degli smartphone ed oggi e presente anchenella maggior parte dei tablet. Alla scheda SIM e associato un credito telefonico, grazie alquale e possibile usufruire di servizi a pagamento come telefonate, SMS e traffico dati. Seun attaccante riuscisse a prendere il controllo del dispositivo, potrebbe avere facile accessoa tali risorse economiche. Secondo alcune ricerche [4], il 50% del malware recente sumobile funziona in questo modo, essendo relativamente semplice per l’attaccante ottenereun profitto. Inoltre, poiche dal punto di vista dell’operatore mobile i costi sono addebitaticomunque all’utente finale, e difficile differenziare i casi di sottrazione di denaro illecitoda lecite spese.

1Sorgente immagine: Mobile Security: Finally a Serious Problem?, Neal Leavitt, IEEE Computer Society,June 11

7

• Capacita computazionale e batteria: mediamente, smartphone e tablet non dispongonodella stessa capacita computazionale dei calcolatori fissi, soprattutto in termini di CPU edi disponibilita di memoria RAM. Nonostante i modelli piu performanti possano comun-que avere caratteristiche hardware confrontabili ad alcuni computer desktop, la scarsaautonomia della batteria e un altro fattore limitante. In ambito mobile, non e semplicerealizzare protezioni a livello software basate su processi in continua esecuzione e compu-tazionalmente intesivi. Inoltre, questo punto e particolarmente critico, poiche la duratadella batteria e una delle caratteristiche del dispositivo piu valutate a livello commerciale.

• Sensori: I dispositivi mobili sono in genere dotati di una vasta gamma di sensori che offro-no 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 disposizioneun’enormita 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 attraversoil 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 seguitosono elencati i principali:

• Accesso a dati privati. I dispositivi mobili sono un mezzo di archiviazione di materialepersonale, 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 applicazionisono molto interessanti. Inoltre le informazioni potrebbero anche essere eliminate o mo-dificate. Un esempio e l’applicazione SpyPhone2, per Android ed iOS, che viene eseguitain background ed e in grado di fornire ad un utente remoto informazioni relative a SMS,chiamate, email, inviare fotografie, informazioni di localizzazione, registrare audio ed altreancora.

• Furto d’identita. Uno smartphone costituisce indirettamente una forma di autenticazio-ne del suo possessore grazie alle informazioni contenute, al contratto telefonico a cui eassociato ed alle password che memorizza.

• Overbilling. Con questo termine si indicano gli attacchi volti ad utilizzare il creditotelefonico associato ad un dispositivo, ad insaputa dell’utente. Ad esempio, inviandoSMS automaticamente o effettuando chiamate verso numeri a pagamento.

• Estorsione di denaro. In questa categoria rientrano i ransomware, software malevoliche applicano delle limitazioni nell’utilizzo del dispositivo e successivamente richiedonoil pagamento di un riscatto (ransom in Inglese) per rimuovere il blocco. Un esempio eSimpLocker [6], un ransomware per Android, responsabile di cifrare alcune file importantie di impedire qualsiasi operazione sul dispositivo, reindirizzando l’utente sempre allaschermata di sblocco. Si rimanda ad un’analisi dettagliata in 1.2.4.

• Lo sfruttamento della capacita computazionale. Nonostante, come precedentemente detto,la capacita computazionale di un dispositivo mobile non sia attualmente comparabile conquella di un calcolatore fisso, negli anni si e assistito ad una crescita della velocita dellaCPU e della disponibilita di memoria RAM. Combinata con collegamenti internet ad altavelocita, rende i dispositivi mobili molto appetibili per l’utilizzo in contesti malevoli, comead esempio le botnet [7].

2http://www.spy-phone-app.com

8

• Denial Of Service. Si tratta di un attacco che mira a generare un disservizio. In gene-rale, e facilmente individuabile e raramente crea un danno irreversibile nel dispositivo.Principalmente genera sconforto nell’utente attaccato. Gli attacchi spaziano da una dimi-nuzione delle prestazioni, del livello di carica della batteria, fino al blocco del dispositivoda remoto.

1.2.3 Canali di attacco

I principali attacchi a dispositivi mobile sfruttano sia i canali di comunicazione disponibili, chele applicazioni malevoli.

Canali di comunicazione

• Servizi di rete mobile tradizionali come GSM, 3G, 4G. Esempi sono gli attacchi di over-billing per il cellulare Siemens S55 [8] o il buffer overflow negli MMS su Windows MobileCE. 4.2 [9].

• Wi-Fi : il traffico di una rete Wi-Fi puo sempre essere sniffato. Il pericolo e maggiore sela rete e pubblica oppure se la protezione adottata e debole, come nel caso del protocolloWEP.

• Bluetooth: gli attacchi Bluetooth sono utilizzati anche per la diffusione di malware tradevices. Un esempio e Il worm Cabir [10], che visualizza il fastidioso messaggio “Caribe”all’accensione del dispositivo. Gli attacchi su Bluetooth sono generalmente limitati dallanecessita di vicinanza tra i dispositivi.

• USB : la connessione USB e comunemente utilizzata per sincronizzare il dispositivo mo-bile con il PC. Viene anche utilizzata dagli sviluppatori come interfaccia per il debugdelle applicazioni. La sua gestione e importante: l’accesso fisico al dispositivo potrebbepermettere di ottenere informazioni riservate e di installare applicazioni malevoli.

Malware Il malware e un software progettato per eseguire un payload ostile, intrusivo odannoso ad insaputa dell’utente. Attualmente il principale vettore di distribuzione del malwaree Internet. Ad esempio, puo essere nascosto nel codice Javascript di una pagina web, in unapplicazione 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 diamministratore del sistema), ransomware (limitazione dell’accesso ai file del dispositivo conrichiesta di riscatto). Tuttavia, e bene notare che le minacce moderne difficilmente possonoessere classificate in una sola delle categorie sopra elencate in quanto frequentemente combinanopiu varianti.

La somiglianza tra i sistemi operativi mobile con quelli tradizionali ha favorito la migrazione disoftware malevoli, inizialmente nati per essere eseguiti su PC, sui nuovi dispositivi. Tuttavia,la scarsa capacita computazione e le limitazioni imposte dalla batteria rendono le classichesoluzioni 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 discansione ottimizzati, saranno analizzate in dettaglio nel corso del report.

9

Figura 2: Il messaggio visualizzato da SimpleLocker. 3

1.2.4 Esempio di malware: SimpLocker, un ransomware per Android

Viene di seguito analizzato SimpLocker, un ransomware per Android. Nonostante attualmentesia diffuso solo per la piattaforma Android, le tecniche impiegate sono generali ed applicabilianche ad altri sistemi operativi mobile.

Introduzione Verso meta del 2013 Symantec ha rilevato Android Defender (rinominato dalleaziende di Anti-Virus Android.Fakedefender), il primo ransomware per Android [12]. Si trattadi un’applicazione che, fingendo di effettuare una scansione e rilevando minacce non esistenti,blocca il dispositivo fino al pagamento di un riscatto. Il ransomware e un tipo di malware bennoto che impedisce all’utente l’accesso ai propri file fino al pagamento di un riscatto.

Un anno dopo, a meta del 2014, Symantec ha individuato una nuova variante di ransomware perAndroid, conosciuta come SimpLocker, che impedisce l’accesso ai file del dispositivo cifrandoli.L’applicazione che distribuiva il malware in questione e Sex Xonix, un gioco all’epoca disponibilesu Google Play Store.

SimpleLocker [13] e una versione semplificata di una famiglia di ransomware molto diffusi sul-la piattaforma Windows desktop: Dirty Decrypt, CryptoLocker, CryptoWall, CryptoDefense,TorrentLocker e Cryptographic Locker.

Il malware e disponibile su Android in differenti versioni: 30 sono le varianti conosciute dalleaziende Anti-Virus, rappresentate tutte con il nome di Android.SimpLocker.

Una volta che l’applicazione viene scaricata ed installata sul dispositivo mobile, il malwarevisualizza un messaggio a tutto schermo, riportato in Figura 3, indicando che il telefono estato bloccato a causa della presenza e diffusione di contenuti pedopornografici. Per sbloccare

3Sorgente immagine: http://static.spiceworks.com/shared/post/0002/2091/Fig2 6.png

10

il dispositivo e necessario effettuare un pagamento. Il messaggio puo essere chiuso, ma vieneimmediatamente visualizzato nuovamente se l’utente tenta di lanciare un’altra applicazione.Per una maggiore intimidazione, alcuni versioni utilizzano anche la fotocamera del telefonoper catturare la faccia dello sfortunato possessore e minacciano di mandarla ovunque l’autoredel malware lo ritenga necessario. Diverse versioni del malware differiscono nel messaggiointimidatorio, 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 modalita 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 quellipiu allarmanti, come la possibilita di effettuare chiamate e di mandare SMS, inoltre non vie la richiesta dei privilegi di root. E comprensibile, quindi, che gli utenti continuassero conl’installazione dell’applicazione.

I componenti Il malware e composto da cinque componenti:

• Una Main Activity: si attiva quando l’utente tocca l’icona sullo schermo. Lo scopoprincipale e quello di bloccare lo schermo, visualizzare un messaggio intimidatorio edeseguire il servizio MainService. Tutti i messaggi intimidatori sono memorizzati nel fileAPK come stringhe di testo ed lo schermo viene bloccato intercettando se vengono premutii tasti di Home, Indietro e Menu.

• Due BroadcastReceiver: ServiceStarter e SDCardServiceStarter. Il primo viene eseguitoquando il sistema viene avviato. Il secondo si avvia quando e disponibile una scheda SDe si occupa di cifrare i file.

• Due Service: MainService and TorService. Il primo si occupa di fornire le funzionalita dibase del malware. TorService e responsabile della comunicazione con il command servertramite la rete Tor.

Ricerca e Cifratura dei File Se una scheda di memoria SD e presente nel telefono, ilservizio SDCardServiceStarter si occupa della ricerca e cifratura di tutti i file con le seguentiestensioni: .3gp, .avi, .bmp, .doc, .docx, .gif, .jpeg, .jpg, .mkv, .mp4, .pdf, .png, .txt. I filevengono cifrati usando Java Cryptography Extension (JCE) che implementa gli algoritmi dicrittografia di base. Il malware utilizza un algoritmo di cifratura simmetrica AES 256 bit, conmodalita Cipher Block Chaining (CBC). La chiave viene generata a partire da una stringa ditesto, memorizzata nel programma, di cui viene effettuato un hash con algoritmo SHA-256. Lastringa e 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 e possibile ottenere le istruzioni utilizzate per generare lachiave ed utilizzarle per decifrare i file, senza la necessita 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 scrivesulla 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 maggiorecomplessita nella fase di cifratura: impiega AES per cifrare le informazioni iniziali e RSA, unalgoritmo di cifratura asimmetrico, per cifrare i file del dispositivo. La chiave privata vienesalvata nel Command&Control server, rendendo quasi impossibile il recupero dei file senzapagamento del riscatto. Per poter confrontare con maggiore dettaglio le tecniche usate nelledue versioni di malware, di seguito sono elencati i principali passaggi della tecniche di cifraturausati da CryptoLocker:

• Il malware ottiene delle informazioni sul calcolatore della vittima e le cifra utilizzandouna chiave AES-256 bit generata randomicamente [16].

• La chiave AES viene cifrata utilizzando RSA (1024 o 2048 bit a seconda della versionedel malware) con la chiave pubblica hardcoded del server Command&Control.

• Le informazioni sul computer della vittima (cifrate con AES) e la chiave AES (cifrata conRSA) vengono inviate al server.

• Il server decifra la chiave AES utilizzando la propria chiave privata ed in seguito decifraanche le altre informazioni sulla vittima.

• Il server genere una coppia di chiavi asimmetriche RSA (2048 o 4096 bit a seconda delleversioni), che saranno utilizzate per la cifratura dei file da parte del malware.

4Sorgente immagine: http://www.symantec.com/connect/blogs/ simplocker-first-confirmed-file-encrypting-ransomware-android

12

• La chiave pubblica generata viene mandata al client cifrata, utilizzando la chiave AES-256bit precedentemente inviata.

Connessione con il Command Server La connessione con la rete Tor5 assicura la comu-nicazione 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 diret-tamente nel programma, differenti versioni utilizzano nomi diversi. Dopo aver stabilito unaconnessione, 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 paga-mento e stato effettuato. In seguito alla conferma del pagamento, un messaggio di risposta dalserver (stop) permette di sbloccare lo schermo e decifrare i file precedentemente cifrati.

Rimozione dell’applicazione malevole In alcuni dispositivi Android, il malware puo essererimosso velocemente disinstallando l’applicazione Sex Xonix, dopo aver riavviato il dispositivo.Tuttavia, nella maggior parte dei casi l’applicazione viene caricata cosı velocemente dal sistemada 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 funzionalita di base dell’OS ed impe-disce che applicazioni di terze parti vengano eseguite. Android.Simplocker puo essere rimossoeseguendo il sistema operativo con questa opzione. Se dopo l’installazione dell’applicazionemalevole il dispositivo viene immediatamente spento, si puo prevenire che molti file venganocifrati. In seguito si puo procedere alla disinstallazione, come precedentemente spiegato, o adun factory reset, riportando il dispositivo alle impostazioni di fabbrica.

Tutti i file cifrati, possono essere decifrati in quanto la chiave utilizzata dall’algoritmo di cifra-tura simmetrica viene salvata all’interno del malware. Tuttavia non risulta essere un’operazionesemplice per la maggioranza degli utenti che non sono familiari con gli algoritmi di cifratura.

Conclusione Android.Simplocker e il primo ransomware conosciuto per Android che cifrai file, rendendone impossibile l’accesso. Nonostante questa versione del malware sia moltosemplice, soprattutto se confrontata con Cryptolocker, vi e molto spazio per miglioramentifuturi.

1.2.5 Proteggersi dagli attacchi

La protezione dalle minacce descritte in 1.2.2 e 1.2.3 puo essere implementata su diversi livelli,di seguito elencati.

• Rete. A livello di rete e possibile monitorare il traffico alla ricerca di anomalie ed imple-mentare alcuni filtri basati sul riconoscimento di patterns malevoli. Nel caso degli SMS,ad esempio, si potrebbe sospettare un traffico anomalo nella quantita di essi, provenientedallo stesso numero telefonico.

• Il sistema operativo. In ambito mobile rappresenta il tipo di protezione piu 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, isecondi mirano a prevenire ed, in caso, a limitare i danni inflitti da un software malevole

5https://www.torproject.org

13

o da altri attacchi precedentemente descritti in 1.2.3. La strategia di prevenzione siconcretizza soprattutto nella realizzazione del “Confinamento delle applicazioni”, uno deipunti centrali dell’analisi (sezioni 2.5, 3.3, 4.5).

• Store. E il negozio virtuale per la distribuzione di applicazioni. Attualmente ogni sistemaoperativo ha il proprio store ufficiale, ma sono presenti anche versioni multipiattaforma,ad esempio per la distribuzione di applicazioni in tecnologia Web. In ambito mobilerappresenta il primo filtro per evitare la diffusione di applicazioni malevoli, grazie ad unprocesso di revisione che puo essere anche completamente automatizzato. Nelle sezioni2.6, 4.7 verranno trattate in dettaglio le diverse soluzioni adottate per ciascun sistemaoperativo analizzato.

• Utente. Parte degli attacchi non sfrutta falle tecnologiche dei dispositivi attaccati, mautilizza tecniche di social engineering che portano l’utente ad eseguire operazioni dannoseper la sua privacy o per l’integrita del sistema operativo. Prevenire questi problemi e unasfida piu a livello sociale che tecnologico: sono necessarie campagne di informazione edi sensibilizzazione degli utenti verso il problema della sicurezza, affinche siano consape-voli delle sempre crescenti situazioni di rischio legate ad un uso non coscienzioso di unosmartphone. Tuttavia, i sistemi operativi mobile possono offrire un certo livello di prote-zione attraverso notifiche sui possibili rischi legati ad alcune funzionalita, sull’utilizzo diimpostazioni non sicure o addirittura in alcuni casi, impedendo determinate azioni.

Nel corso del report verranno analizzate nel dettaglio le soluzioni di sicurezza offerte a livellodi sistema operativo, store ed utente. Le operazioni di monitoring della rete sono a caricodell’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 ilcustom firmware di Android CyanogenMod. Al fine di rendere il documento piu omogeneo,l’analisi e stata condotta secondo un modello comune. Nonostante la diversita dei sistemianalizzati, sono state selezionate alcune macrocategorie, di seguito dettagliate, in modo dafacilitare l’operazione di confronto tra le soluzioni adottate in ciascun prodotto.

1. Modalita dell’analisi di sicurezza: descrizione del procedimento adottato e delle fontiimpiegate per analizzare il sistema operativo.

2. Introduzione

3. Architettura: descrizione dell’architettura del sistema operativo (il kernel, i componentiprincipali, i livelli in cui e suddiviso). Analisi di eventuali componenti di virtualizzazionee di Framework a supporto delle applicazioni.

4. Il modello di sicurezza del sistema operativo: il modello adottato nella progettazione dellasoluzioni di sicurezza. Una visione d’insieme delle tecniche adottate.

5. Tecniche di confinamento delle applicazioni: l’impiego di eventuali tecniche di isolamen-to delle applicazioni per prevenire e limitare le conseguenze di possibili attacchi. Talitecniche consistono nell’isolare ciascuna applicazione, impedendone l’interazione con lealtre. Inoltre, si vuole limitare l’accesso ai componenti del dispositivo e ai dati sensibilimemorizzati.

14

6. Criticita progettuali ed implementative delle applicazioni: valutazione di possibili pe-culiarita progettuali o implementative che introducono debolezze nella sicurezza delleapplicazioni.

7. Store: analisi del negozio virtuale, nel caso in cui sia disponibile, per la distribuzione diapplicazioni per dispositivi mobili. Il servizio generalmente permette di navigare tra leapplicazioni compatibili con il proprio dispositivo e di scaricarle direttamente sullo smart-phone o tablet, sia gratuitamente, che a pagamento. Si vogliono analizzare le possibilifunzioni offerte, tra cui quella di filtrare la pubblicazione di applicazioni sulla base di unprocesso di revisione al fine di limitare la diffusione di applicativi malevoli o non adatti,nei contenuti, per gli utenti.

8. Cifratura: eventuali funzionalita finalizzate a limitare l’esposizione e la perdita di dati sen-sibili memorizzati all’interno dei terminali, in particolare a seguito della compromissionefisica 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’accessofisico, il primo livello di protezione applicabile sui dispositivi mobili. E finalizzato ad ini-bire l’uso non autorizzato in caso di smarrimento o furto ed a proteggere i dati contenutial suo interno. In questo contesto rientrano l’impiego della password impostabile dall’u-tente ed il blocco automatico del dispositivo dopo un certo periodo di inattivita. Misureaddizionali riguardano la possibilita di effettuare un reset hardware o la cancellazione deidati da remoto.

11. Vulnerabilita note: eventuali falle di sicurezza note pubblicamente, alle quali e statoassegnato un Identificatore CVE (Common Vulnerabilities and Exposures).

12. Analisi sperimentale: eventuale utilizzo dell’emulatore o di un dispositivo fisico per pro-vare le nozioni acquisite, testare le impostazioni di sicurezza insieme a possibili debolezzedel sistema operativo.

13. Conclusione: note conclusive sull’analisi del sistema operativo. Punti di forza, debolez-ze, migliorie. Confronto delle soluzioni adottate con quelle offerte nel panorama dellasicurezza mobile.

L’analisi e stata condotta in collaborazione con il Security Lab di “Telecom Italia InformationTechnology”. Si ringraziano Roberta D’Amico, Dario Lombardo per il supporto offerto.

In accordo con le loro esigenze, si e deciso di analizzare i tre sistemi operativi con un livello didettaglio crescente secondo l’ordine: CyanogenMod, Ubuntu Touch e Tizen. Questa scelta edettata anche dal livello di interesse e particolarita dei sistemi in questione. Tizen e indubbia-mente il piu interessante ed innovativo nelle soluzioni di sicurezza. Ubuntu Touch e un ramo diUbuntu, che si vuole aprire al mondo mobile conservando la struttura della versione desktop.Infine, CyanogenMod e una variante di Android, che rilassa alcuni stretti vincoli di sicurezza avantaggio di maggiori funzionalita.

1.4 Conclusioni

La rapida diffusione dei dispositivi mobili, combinata con le maggiori funzionalita offerte, hareso il problema della sicurezza di fondamentale importanza, anche in ambito mobile. La

15

disponibilita di una connettivita quasi sempre presente, rende i dispositivi mobili soggetti adiversi tipi di attacco, che possono arrecare un danno economico, materiale, o violare la privacydei loro possessori. E evidente che siamo all’inizio di un’era in cui gli attacchi saranno semprepiu sofisticati. Progettare nuove soluzioni di sicurezza ad hoc e una sfida tanto necessaria quantodifficile: l’adozione delle stesse misure adottate su calcolatori classici e ostacolata dalle limitaterisorse che i dispositivi mobili offrono, in termini di capacita computazionale, ma soprattuttoper l’autonomia di carica. In questo contesto, e fondamentale il ruolo del sistema operativomobile, che racchiude quasi interamente le funzioni di sicurezza adottabili.

16

2 Ubuntu Touch

Figura 4: Schermata home di Ubuntu Touch6

2.1 Modalita dell’analisi di sicurezza

Si analizzano ora le caratteristiche di sicurezza di Ubuntu Touch. L’analisi e stata condottaprincipalmente sulla base della documentazione ufficiale del sistema operativo presente online.Oltre a cio, la natura open source di Ubuntu Touch ha consentito di esplorare le discussionipubbliche degli sviluppatori sulle piattaforme online di codesharing, tra cui Launchpad7. Sie anche preso diretto contatto con alcuni sviluppatori tra cui Marc Deslauriers, esperto di si-curezza in Canonical8 e uno dei piu contribuenti sviluppatori di Ubuntu, il quale ha fornitoconsigli su come affrontare l’analisi e chiarimenti. Infine, e stato utilizzato l’emulatore ufficialedi Ubuntu Touch9 al fine di poter testare la navigazione attraverso le funzionalita del sistema.In generale, si vuole specificare che l’attuale condizione di sistema operativo neonato ha resoparticolarmente difficile la ricerca di informazioni. La documentazione ufficiale cambia di mesein mese e contiene a volte informazioni non aggiornate. Alcune delle strategie di sicurezza da

6Sorgente immagine: https://lwn.net/Articles/540146/.7www.launchpad.net8Canonical e la compagnia che sta dietro allo sviluppo di Ubuntu9Al momento estremamente limitato.

17

www.launchpad.net

adottare sono attualmente ancora in discussione. Lo stato dell’arte, in termini di documenta-zione e analisi, relativo a Ubuntu Touch e estremamente limitato se non inesistente. Secondole nostre ricerche, la presente analisi rappresenta il primo documento che riunisce in modoordinato i diversi aspetti di sicurezza di questo sistema operativo. Le suddette ragioni, unitealla difficolta di reperire un dispositivo compatibile con Ubuntu Touch (il primo modello dismartphone con Ubuntu Touch preinstallato e uscito a inizio 2015), hanno portato ad optareper un’analisi di tipo documentativa e non sperimentale. Poiche, come sara mostrato nellasezione 2.3, l’architettura software di tale sistema operativo coincide in gran parte con quelladi Ubuntu Desktop, ed essendo una completa analisi della sicurezza di Ubuntu al di fuori degliintenti di questo report, si e deciso di analizzare gli aspetti del sistema operativo che hannomaggior rilevanza ai fini dell’utilizzo in ambiente mobile.

2.2 Introduzione

Ubuntu Touch e 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 moltoUbuntu Desktop nelle forme e colori. Sebbene la versione desktop e mobile siano al momentodistribuite distintamente, in realta e bene chiarire che dal punto di vista architetturale non sitratta di due sistemi distinti [18]: Ubuntu Touch e di fatto Ubuntu 14.04, a cui comunementeviene aggiunto il suffisso Touch nel caso sia utilizzato in ambiente mobile10. Si spiega megliol’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 capacita computazionale e funzionalita imparagonabilia quelle dei sistemi fissi. Per questo motivo, il loro campo di utilizzo e rimasto per anniben distaccato da quello dei comuni calcolatori. Come presentato nell’introduzione, l’era deglismartphone sta annientando queste differenze. Ad oggi e possibile fare coi nostri smartphonequasi tutto cio che i sistemi desktop permettono. Eppure, nonostante queste differenze intermini di utilizzo stiano scomparendo, le strutture software che li governano ereditano dalpassato profonde differenze che ostacolano una totale integrazione dei due sistemi. Difficilmentesi puo 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 esempioGoogle Drive), la strada pare ancora lunga, e porta con se diverse problematiche legate allanecessita di una connessione internet. Finche dispositivi mobili e fissi erano dedicati a scopidistinti, tale mancanza di integrazione non rappresentava un problema. Oggi che e possibilegestire 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 modernidispositivi mobili possono avere le caratteristiche sufficienti per eseguire un sistema operativodesktop, si e pensato di lasciarsi alle spalle la storica divisione tra i due mondi, portando su talidispositivi lo stesso Ubuntu desktop. Il kernel Linux si adatta bene a diversi tipi di architetturehardware e, come l’esperienza Android dimostra, puo facilmente essere utilizzato anche su questi

10La 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 digestione 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 e di unificare il mondo mobile e desktop, otte-nendo 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 computerfisso e mostrare all’utente un classico sistema operativo desktop. Ad oggi la convergenza non estata ancora portata a termine, e Ubuntu Touch (o meglio, l’adattamento di Ubuntu ai dispo-sitivi mobili) e ancora da considerarsi un sistema in via di sviluppo. Al momento e possibileinstallarlo solo su alcuni device di casa Google (Nexus 4, Nexus 7, Nexus 10) e, da Febbraio2015, e 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 sareb-be giunta a completamento con Ubuntu 16.04 LTS. Ora tale pagina e stata rimossa per motivia 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 conl’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 kernelinizialmente incluso era la versione 3.13, ma e stato aggiornato alla 3.16 con il rilascio diUbuntu 14.04.2 nel Febbraio 2015. Si descrivono ora le componenti di piu alto livello.

2.3.1 LXC - Linux Container

Un LXC (Linux Container) e 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 piu approfondita sifaccia riferimento all’appendice 6.6.

Si mostrano le ragioni della presenza di un LXC nel caso in questione. Ubuntu Touch staindubbiamente entrando nel mercato in ritardo rispetto ai propri concorrenti. Voler sviluppareun sistema in grado di essere eseguito sul maggior numero di dispositivi possibile richiede diavere a disposizione per ciascuno di essi i driver di basso livello necessari. Come dichiaratoda Ricardo Salveti all’Embedded Linux Conference 2014, chiedere ai produttori di dispositividi rilasciare i driver compatibili con Ubuntu sarebbe stato impossibile. Ubuntu Touch risol-ve questo problema eseguendo all’interno di un LXC l’Android HAL (Hardware AbstractionLayer), al fine di utilizzarne i driver e alcuni demoni necessari per la gestione dell’hardware deldispositivo sottostante.

Come si e detto, il container deve essere ospitato da un altro sistema Linux based, nel nostrocaso Ubuntu. Poiche nel nostro caso l’LXC contiene i driver necessari alla comunicazione conil dispositivo, il suo avvio avviene durante le primissime fasi del boot. Non appena il sistemae pronto, l’LXC viene avviato e genera al suo interno il proprio file system. Al termine del suocaricamento, il processo di boot standard puo proseguire ed avviare tutte le funzionalita di piualto livello. Da questo momento in avanti, le applicazioni possono dialogare con il container, e

11La lista aggiornata dei device supportati e disponibile a https://wiki.ubuntu.com/Touch/Devices.12Sorgente immagine: [18].

19

https://wiki.ubuntu.com/Touch/Devices

Figura 5: Architettura Ubuntu Touch 12.

dunque con l’hardware sottostante, tramite libhybrids13, che funge da strato di comunicazionetra i due [19].

2.3.2 Mir

Mir e il display server. E stato sviluppato per rimpiazzare il vecchio X Window System esupportare lo sviluppo di Unity 8, la nuova generazione di Unity user interface. In quantodisplay server, esso controlla e gestisce a basso livello l’integrazione delle parti della GUI. Adesempio, gestisce il mouse e aiuta a combinare i movimenti del mouse con il cursore e gli eventidi interfaccia che il movimento del cursore causa. La Figura 6 mostra alcune delle funzionalitadi Mir.

2.3.3 Unity 8

Unity8 e la shell grafica utilizzata. Fornisce gli strumenti di interfaccia utili ad utilizzare ilsistema nel modo piu 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 e stata infatti progettata nell’intento di avere un’unica implementazione che potessegestire un’interfaccia grafica in grado di adattarsi perfettamente ad una vasta varieta di schermi,in senso di forme e dimensioni: smartphone, tablet, TV, desktop. Inoltre, sempre pensando adun utilizzo nel contesto “converged”, Unity 8 e stata alleggerita rispetto alla versione precedente,al fine di essere adatta ad un hardware piu limitato. Unity 8 e stata sviluppata in gran parte

13Hybris o libhybris e un livello di compatibilita 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 LinuxBionic-based Linux, che includono principalmente librerie Android e driver dei dispositivi.

14Sorgente 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 diun linguaggio basato sull’integrazione di JavaScript e Qt per la progettazione di applicazioni coninterfacce di grande impatto visivo [21]. Qt e una libreria cross-platform, largamente utilizzatanello 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. Possonoessere 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 cheHosted, ovvero residenti su website remoti ed eseguite dal browser. Per richiamare l’espressioneutilizzata nella documentazione ufficiale, le applicazioni Web-based (scritte in HTML5) e quellenative (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, chepermettono ad una applicazione di accedere tramite JavaScript alle funzionalita native deldispositivo quali la fotocamera e l’accelerometro. Combinate con un UI framework, nel nostrocaso Qt, permettono di sviluppare un’applicazione utilizzando solo HTML, CSS, e JavaScript.E previsto anche il supporto per applicazioni scritte in C++, anche se e una pratica menofrequente [23].

21

Distribuzione Tradizionalmente il software per Ubuntu e distribuito attraverso gli Ubuntuarchives. Tale modello e basato sulla fiducia, barriere all’ingresso e tempi lunghi. Per ave-re il permesso di pubblicare un pacchetto all’interno di tale archivio, uno sviluppatore devedimostrare affidabilita contribuendo molto all’interno della community. Imparare a creare emodificare tali pacchetti e renderli conformi alla pubblicazione negli Ubuntu archive e com-plesso, richiede tempo e rappresenta pertanto una grossa difficolta. Inoltre, tali archivi sonoaggiornati solo con le nuove release di Ubuntu, pertanto i tempi richiesti per la pubblicazioneo l’aggiornamento di un’applicazione sono particolarmente lunghi. Questo processo lungo ecomplesso, unito a continui controlli di sicurezza sui pacchetti, garantisce un archivio softwaredi cui gli utenti si possono fidare, ma non rappresenta un canale tramite cui gli sviluppatoripossono portare agli utenti rapidamente le nuove versioni del proprio software.

L’obiettivo della convergenza e, in generale, la nuova apertura verso il mercato dei dispositivimobili, ha reso necessaria l’adozione di un nuovo sistema di distribuzione delle applicazioni. Sivuole avere un modello di App store, semplice, rapido, dinamico, adatto alla distribuzione di unelevato 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 dispo-nibili agli utenti finali. Inoltre, si vuole aggiungere supporto per la creazione di applicazioniche saranno eseguite sotto confinamento.

A tal scopo, parallelamente ai tradizionali Ubuntu archives, e stato aggiunto uno store speciale(al momento non accessibile da browser) dedicato ai cosiddetti Click Packages. Si tratta diun nuovo formato di packaging utilizzato in Ubuntu Touch e, a partire da Ubuntu 14.10, sullaversione Desktop. I Click package semplificano notevolmente il lavoro dello sviluppatore. Pos-sono essere creati grazie ad una procedura automatizzata tramite l’Ubuntu SDK, che permetteinoltre la specifica delle impostazioni di confinamento. La procedura di caricamento onlinedei Click package richiede pochi minuti attraverso il portale“My Apps” di Ubuntu, e li rendequasi immediatamente disponibili agli utenti. Dettagli saranno discussi in 2.6. Non esistendoancora un nome specifico per lo store online che distribuisce i Click packages, d’ora in avan-ti lo denoteremo con “App store”, al fine di distinguerlo dai tradizionali repository (Ubuntuarchives).

Applicazioni trusted e untrusted Le applicazioni possono essere distinte in due macrogruppi: untrusted e trusted dall’OS. Le applicazioni untrusted sono quelle scaricate dall’Appstore, per le quali il processo di pubblicazione e piu semplice. Tali App sono obbligatoriamenteconfinate da un profilo AppArmor (vedremo di cosa si tratta in 2.5). I controlli dello store suqueste App possono essere, sotto opportune condizioni che vedremo in 2.6, automatici. Le Appnon fidate possono accedere solo ai propri dati e a quanto espressamente concesso dall’utente,non possono accedere a funzioni privilegiate del OS, ne a particolari API come quelle per latelefonia. Con l’autorizzazione dell’utente, esse possono accedere ad API sensibili come lalocalizzazione o online accounts. Tipicamente non sono supportate da Ubuntu o Canonical.

Le applicazioni fidate sono invece quelle installate come parte integrante del sistema operativoo distribuite da Ubuntu/Canonical. Di norma queste applicazioni non sono eseguite confinate.Tali applicazioni possono tipicamente accedere ad ogni risorsa o dato disponibile all’internodella sessione dell’utente. Hanno accesso limitato ai servizi e dati di sistema secondo il si-stema tradizionale di permessi Unix. Sono supportate da Ubuntu e/o Canonical e di normacostantemente aggiornate.

22

2.4 Modello di sicurezza del sistema operativo

Garantire massima sicurezza e uno dei principi fondamentali dello sviluppo di Ubuntu Touch. Siriassumono brevemente i punti chiave su cui si basa il modello di sicurezza adottato, indicandoin quali sezioni di questo report sono analizzati.

• Distinzione tra applicazioni Trusted e Untrusted (2.3.4): a seconda della provenienza diuna applicazione, le politiche di confinamento possono essere o meno necessarie.

• Confinamento applicazioni (2.5): e 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, e possibi-le specificare singolarmente a quali percorsi del file system una applicazione puoaccedere.

– Protezione accesso a sensori e particolari tipi di dato (2.5.4 e 2.5.5): anche peri sensori e dati quali la musica, galleria fotografica, calendario ecc... e possibiledefinire 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 discambiare dati tra loro, e cio deve avvenire in modo sicuro.

• Controllo a livello di store (2.6)

– Verifica applicazioni : al fine di garantire un App store funzionale e al contemposicuro, e necessario affiancare processi di revisione delle App automatici ad altrimanuali.

– Firma applicazioni : il dispositivo deve poter scaricare applicazioni solo da fontiattendibili e verificarne l’autenticita.

• Memorizzazione dati critici (2.7): le applicazioni necessitano di un luogo centralizzatoper la gestione di dati critici.

• Cifratura dati utente(2.8): consente di proteggere la segretezza dei dati anche nel caso incui protezioni a livello software (di sistema operativo) non fossero efficaci.

• Protezione dell’accesso(2.9): e il sistema base con cui viene impedito lo sblocco deldispositivo ad un utente non autorizzato.

2.5 Tecniche di confinamento delle applicazioni

2.5.1 La necessita di confinare le applicazioni in Ubuntu

L’introduzione di un App store per la distribuzione dei Click package introduce alcune problema-tiche di sicurezza: il processo semplificato puo facilitare la pubblicazione di malware all’internodello store, oppure permettere che applicazioni con falle di sicurezza arrivino direttamente agliutenti. Ubuntu deve essere pronto ad ospitare in modo sicuro grandi quantita di software nonfidato. Cio implica la necessita di confinare le applicazioni. Tecniche di confinamento delleapplicazioni sono di uso comune in tablet e smartphones. Da quanto detto in precedenza sullaconvergenza, dovrebbe essere chiaro che, nel nostro caso, le soluzioni adottate per confinarele 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 edesktops. Tali soluzioni, inoltre, necessitano di essere facilmente compatibili con applicazionigia esistenti. Un’applicazione confinata deve avere il permesso di leggere e scrivere dati soloda locazioni che sono state precedentemente approvate dall’utente e lo stesso principio vale perl’uso dei sensori. L’implementazione di una soluzione deve essere il piu semplice possibile, enon deve avere impatto sul tempo di startup di un’applicazione. Anche il sistema di gestionedei diritti delle applicazioni necessita di essere semplice e comprensibile. La soluzione adottatain Ubuntu si chiama AppArmor.

2.5.2 Introduzione ad AppArmor

AppArmor e un modulo di sicurezza del kernel Linux che implementa un MAC (Mandatoryaccess control). Insieme al tradizionale sistema Unix dei permessi utente, permette di limitarele App a un limitato set di risorse. AppArmor e una tecnologia gia matura, utilizzabile perconfinare applicazioni su ogni installazione default Ubuntu a partire dalla versione 7.10 (UbuntuGutsy Gibbon).

Il livello di confinamento che AppArmor adotta su ogni applicazione e definito da profili asso-ciati alle applicazioni e memorizzati all’interno del kernel. Se un profilo non viene specificatoper un particolare binario, tale binario non sara confinato. In tal caso, tuttavia, saranno semprevalide le restrizioni imposte del tradizionale sistema dei permessi utente Unix. Nel caso di unprogramma in esecuzione sotto un determinato profilo AppArmor, qualora questo dovesse ten-tare l’accesso ad un percorso non autorizzato, AppArmor impedira tale accesso e il programmapotrebbe andare in crash.

Focalizzandoci maggiormente su AppArmor, il diagramma di Figura 7 rappresenta il suofunzionamento.

Figura 7: Architettura AppArmor 15.

Nella parte inferiore della figura si trova il kernel. Il LSM (Linux Security Module, [24]) eun modulo del kernel Linux che consente di supportare dei MAC policy engine esterni (come

15Sorgente 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 possibilitadi operare a livello kernel pur non facendone propriamente parte. Cio consente di conservareall’interno di AppArmor le policy di sicurezza per ogni applicazione, evitando di dover applicarepatch al kernel tutte le volte che si ha il bisogno di modificarle. Fondamentalmente, LSM chiedead AppArmor se le operazioni che un’applicazione vuole eseguire possono essere concesse. Nellaparte superiore dell’immagine si trova l’AppArmor management software (nello schema sempli-cemente AppArmor), che rappresenta l’insieme di tool per modificare manualmente le policy.In arancione sono rappresentate le applicazioni, ognuna delle quali potra avere un’AppArmorpolicy corrispondente che ne descrive i permessi.

Secondo i progettisti di AppArmor, portare la sicurezza a livello kernel, come permesso dal-l’interfaccia LSM, e di importanza fondamentale ai fini di garantire la sicurezza. Come CrispinCowan, direttore del Software Engineering Security Architect, ha detto, la sicurezza fatta alivello di libreria e solo apparente, sembra che le applicazioni non possano fare quel che gli evietato, ma l’attaccante che riesce a infettare l’applicazione puo bypassare la libreria e arrivareal kernel. Questo, invece, non e il caso della sicurezza a livello di kernel [25].

E risaputo che, di norma, una lista di permessi puo essere espressa secondo un modello blacklist (in cui tutto e concesso a parte quanto espressamente vietato) oppure white list (in cui tuttoe vietato tranne quanto espressamente concesso). Il secondo e indubbiamente un modello piusicuro, ma piu difficile da mantenere perche per funzionare bene richiede che nessun permessodi quelli necessari sia omesso. Quello di AppArmor e una sorta di modello ibrido: a livello diapplicazione usa una white list, perche specifica i percorsi a cui essa puo accedere, quando tuttigli altri sono vietati. A livello di sistema e invece una black list, perche solo le applicazioni conuna policy definita saranno ristrette. Quando un eseguibile viene lanciato, il kernel esamina ilsuo percorso e cerca se esiste una policy definita da applicare per tale applicazione. Se non latrova, l’applicazione sara avviata non confinata.

Tramite la aa-exec utility e possibile eseguire un certo programma sotto un determinato profiloAppArmor, specificato a parte, e tramite l’API aa change profile si puo cambiare profilo aun programma durante l’esecuzione. AppArmor si occupa inoltre di far ereditare le policy delparente 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’applicazionepuo accedere. In particolare puo specificare:

• Controllo di accesso sui singoli percorsi;

• Controllo di accesso a funzionalita di sistema [26];

• Controllo di accesso a D-Bus;

Si mostra di seguito un esempio di profilo AppArmor:

#inc lude <a b s t r a c t i o n s /base>

c a p a b i l i t y sys t ime ,c a p a b i l i t y sys chroot ,

dbus ( send )

25

bus=s e s s i o npath=/org / f r e ede sk top /DBusi n t e r f a c e=org . f r e ede sk top . DBusmember=Hel lopeer=(name=org . f r e ede sk top . DBus) ,

deny s i g n a l ( send ) s e t =( i n t ) ,

/ e t c /ntp . conf r ,/ e t c / ntpkeys x ,/tmp/ntp∗ 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 e concesso l’accesso.Una lista delle capabilitie supportate e disponibile in [26].

• Successivamente si trova la dichiarazione di un permesso di tipo D-Bus. D-Bus e ilmeccanismo utilizzato in Ubuntu e molti altri sistemi POSIX per l’IPC (Inter ProcessCommunication).

• La keyword signal e utilizzata a partire da Ubuntu 14.04 LTS per specificare quali segnaliun’applicazione puo inviare e/o ricevere. Nel caso visto sopra, si vieta all’applicazione diinviare 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’usodi regular expressions.

Visto questo formato del profilo AppArmor di un’applicazione, appare complicata la gestionedi permessi quali “accesso alla fotocamera”. Per questo motivo sono utilizzati i Policy Groups.

Confronto con SeLinux SeLinux e un modulo per il kernel Linux che fornisce, come Ap-pArmor, la possibilita di implementare Mandatory Access Control. Questo, anziche utilizzarepercorsi, assegna i programmi a certi domini e certi tipi (etichette) ai file. Le policy specifi-cano quali domini possono accedere a quali etichette. Il problema di SeLinux e che i file conla stessa etichetta fanno parte della stessa classe di equivalenza: se in futuro si introduce unnuovo programma che vuole considerare distintamente due file etichettati in modo uguale, bi-sognera introdurre nuove etichette e apportare modifiche anche alle configurazioni dei vecchiprogrammi. Per dettagli su SE-Linux vedere [27].

2.5.4 Policy Groups

Specificare il profilo AppArmor direttamente all’interno del package dell’applicazione rappre-senterebbe una grande complicazione nella mani dello sviluppatore, non in linea con la filosofiavolta alla semplificazione discussa precedentemente. Inoltre, permettere agli sviluppatori discrivere manualmente il profilo AppArmor per le applicazioni destinate allo store online, ren-derebbe 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. Ilprofilo AppArmor non viene scritto manualmente dagli sviluppatori, bensı generato automati-camente al momento dell’installazione sulla base di direttive di piu 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 specificatii 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 e possibile indicare un template da cui partire, che rappresentaun insieme di regole AppArmor predefinito, adatto ad un particolare tipo di applicazione. Almomento 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 UbuntuWebapps.

• ubuntu-scope-network: template specializzato per gli scopes16 che richiedono accessoa internet. Di norma agli Scopes non e concesso utilizzare la stessa gamma di PolicyGroups concessa agli altri tipi di applicazione.

• unconfined: fornisce permessi massimi all’applicazione. Questo template e riservatoad applicazioni che sono specificamente fidate e non puo essere utilizzato da normalisviluppatori.

Di seguito si mostra un esempio di file manifest.json. Il file contiene un oggetto “Hooks” chetrasporta le informazioni di nostro interesse. Potrebbe apparire ad esempio in questo modo:

{[ . . . ]hooks : {

myApp: {apparmor : myApp. json ,content−hub : myAppCH. j son }[ . . . ]

}}

[ . . . ]}

16In Ubuntu Touch, uno scope e una sorta di widget posizionabile nella schermata di home.

27

Cio vuol dire che il file myApp.json contiene sia le informazioni relative ad AppArmor, siaquelle specifiche per il content-hub (vedremo in seguito di cosa si tratta). Il file myApp.jsonpotrebbe avere un contenuto come il seguente, in cui comunica che si vuole poter accedere allavideocamera, al GPS e al microfono.

{p o l i c y g r o u p s : [

camera ,microphone ,l o c a t i o n] ,

p o l i c y v e r s i o n : 1}

Al momento dell’installazione, un tool automatico di nome aa-easyprof crea il profilo Ap-pArmor corrispondente al template e ai Policy Groups specificati. Come mostrato in Figura8, ognuno dei possibili Policy Groups rappresenta diverse entry nel formato AppArmor. Eimportante notare che, come sara illustrato in 2.5.5, specificare ad esempio camera nei policygroups, non significa che, una volta installata, l’applicazione avra il permesso di accedere allafotocamera: servira un ulteriore consenso dell’utente, fornito attraverso i cosiddetti TrusterHelpers.

Figura 8: Scelta Policy Groups 17

La lista di Policy Groups svolge, inoltre, il ruolo di semplificare il processo di revisione di un’ap-plicazione. Lo store legge automaticamente il contenuto del file manifest e ne estrae i permessirichiesti. Qualora fossero richiesti Policy Groups non considerati pericolosi, l’applicazione sa-rebbe immediatamente accettata. In caso contrario, potrebbe subire un processo piu lungo direvisione manuale.

2.5.5 Gestione autorizzazioni: Trusted Helpers

Si e visto come il profilo AppArmor di un’applicazione specifichi con quali servizi tale appli-cazione possa comunicare e a quali percorsi possa accedere. Il permesso di comunicazione con

17Sorgente immagine: https://developer.ubuntu.com/en/publish/security-policy-groups/.

28

servizi che gestiscono dei dati o sensori, non e pero sufficiente a consentire all’App l’accesso aquesti ultimi. Serve esplicita autorizzazione dell’utente, si mostra ora come.

Nel modello di sicurezza adottato, gli utenti prendono decisioni riguardo la concessione dioperazioni sensibili nell’esatto momento in cui esse sono richieste. Cio e ottenuto attraverso l’usodi componenti che prendono il nome di Trusted Helpers. In generale, gli helpers sono processiche gestiscono l’accesso di una applicazione a dei servizi esterni: ad esempio, esiste l’helper dellafotocamera, con cui un’applicazione deve comunicare se vuole scattare foto. Esistono anchehelper per il calendario, i contatti ecc... La comunicazione con tali helper avviene attreversoD-Bus, dunque, poiche le comunicazioni tramite D-Bus sono controllate da AppArmor, il profilodi sicurezza di un’applicazione potrebbe vietare la comunicazione con certi helpers. Qualorainvece il profilo AppArmor concedesse tale comunicazione, l’helper potrebbe gestire l’accessoalla risorsa di sua competenza visualizzando un messaggio di conferma all’utente. In tal casoprende il nome di Trusted Helper. I Trusted Helpers rappresentano dunque il punto in cuil’utente puo prendere la decisione di concedere o negare un certo privilegio, indipendentementeda quanto scritto sul profilo AppArmor. Infatti, il contenuto del profilo AppArmor non evisualizzato 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 filedi manifest rappresentino solo cio di cui l’applicazione potrebbe aver bisogno, ma accettare diinstallare un’applicazione che richiede l’accesso alla fotocamera non vuol dire, come nel modelloAndroid, gia consentire tale accesso, ma significa concedere alla App di richiedere al TrustedHelper della fotocamera di utilizzare tale servizio.

I Trusted Helpers possono anche svolgere funzioni piu complesse che gestire un accesso “boo-leano” di una App. Un esempio e quello degli Online Accounts: la AppArmor policy “onlineaccounts” specifica se una App puo comunicare o meno con l’helper degli Online Accounts,ma tale helper dovra gestire al suo interno la scelta dell’account specifico a cui fornire acces-so. Cio sara fatto attraverso opportuni messaggi di richiesta (ad esempio “Vuoi consentireall’applicazione X di accedere all’account Y?”). Online Accounts puo memorizzare in cache larisposta. Come si puo intuire, questo sistema mischia le policy di AppArmor con quelle deiTrusted Helpers. Infatti, Online Accounts agli occhi dell’utente e come se stesse modificandole policy di sicurezza quando salva la scelta di un utente, sebbene il profilo AppArmor restisempre invariato. In questo modo e possibile dalle impostazioni modificare in un secondo mo-mento i permessi concessi ad una applicazione. Ad esempio sara possibile revocare l’accessoai contatti. Secondo la documentazione, questo modello su due livelli (AppArmor e TrustedHelpers) potrebbe essere rivisto in futuro a favore di uno unico, in modo che sia piu ordinatoe gestibile [28].

2.5.6 Condivisione contenuti: Content Hub

Nonostante le applicazioni siano confinate, esse spesso hanno bisogno di scambiare dati conaltre applicazioni. Si e visto come i Trusted Helpers possano mediare l’accesso a servizi qualifotocamera e GPS, ma come funziona il trasferimento sicuro di file come immagini e musicatra applicazioni? Come puo 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 equello di fornire una API e un servizio runtime che dia alle App la possibilita di condivideree importare contenuto da altre applicazioni. Al momento, lo sviluppo del Content Hub non eancora terminato, tuttavia se ne discutono qui le principali caratteristiche.

Content Hub si basa su alcuni principi chiave:

29

• Il contenuto e proprietario: ogni pezzo di contenuto e posseduto da una e una solaapplicazione. Non esiste un’applicazione che possiede, ad esempio, tutte le immagini.

• Ciascun contenuto ha una App di default: per esempio, l’applicazione predefinita per leimmagini e la Gallery.

• Le applicazioni possono registrarsi come sorgente per un certo tipo di contenuto: questopermette al sistema di mostrare una lista di App sorgenti da cui lo user possa sceglierenel caso voglia importare un file. Oppure, un’App che sta importando puo nominare unaapplicazione sorgente.

• Le applicazioni possono registrarsi come destinazione per un certo tipo di contenuto: ilsistema puo 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 glipresenta una lista di applicazioni tra cui puo scegliere dove salvarla.

• Content transfer object: e l’oggetto che rappresenta un trasferimento. Ha una applica-zione sorgente, una destinazione, del contenuto e uno stato. Una applicazione sorgentecarica il contenuto che vuole esportare all’interno di questo oggetto; quando ha terminato,imposta il transfer state a charged, e il trasferimento puo cominciare.

• Le applicazioni sorgenti di norma forniscono un selector GUI che permette all’user diselezionare il contenuto che desidera, per poi far tornare il focus all’applicazione che staimportando.

Sulla base di questi concetti, viene descritto il funzionamento di Content Hub tramite unesempio. Si immagini che una App voglia importare delle foto da una sorgente di foto didefault.

1. L’applicazione comunica al content hub che essa vuole usare la sorgente di default per leimmagini (Gallery ad esempio).

2. Il Content Hub passa alla App che sta importando un transfer object che la connette allaApp sorgente.

3. Il Content Hub lancia il selector GUI della App sorgente per la selezione delle immaginida parte dell’utente. A quel punto il transfer object viene caricato con le immaginiselezionate e segnato come pronto. Infine la galleria viene chiusa.

4. La nostra applicazione in ricezione vede che il transfer object e pronto (dal suo stato) ede pronta ad importare l’immagine.

5. La nostra applicazione puo utilizzare l’immagine e salvarla in modo permanente utiliz-zando una apposita API (“contentStore”).

Come si e visto, il Content Hub, tramite il trasfer object, fa da intermezzo tra le due applica-zioni. L’utilizzo di un’interfaccia appartenente all’applicazione sorgente per la selezione delleimmagini, garantisce che l’applicazione di destinazione non acceda in alcun modo al contenu-to non desiderato dall’utente. Questo sistema consente inoltre di non dover fornire l’accessocompleto a tutte le immagini, ma solo a quelle desiderate. Figura 9 mostra un confronto tra isistemi di condivisione contenuti utilizzati su diverse piattaforme.

18Sorgente 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 e confinata e puo scambiare contenuto con le altre Apptramite Content Hub.

2. Windows : le applicazioni non sono confinate e possono accedere ognuna al contenutodell’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 applicazionicondividono contenuti tramite questi “pools”.

Registrazione di una App come sorgente o destinazione Come detto, le App che espor-tano contenuto (App sorgenti) hanno bisogno di registrarsi come sorgenti per quel determinatotipo di contenuto. Allo stesso modo, le App si possono registrare per poter essere destinatariedi 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. Rifacendosiall’esempio della sezione 2.5.4, il file myAppCG.json potrebbe contenere il seguente contenutoper segnalarsi come sorgente di immagini [29] [30].

{{

source : [p i c t u r e s ]

}}

2.6 Store

Si tratta ora il percorso di un’applicazione dallo sviluppatore all’utente finale. Nell’interes-se di analizzare particolarmente la sicurezza di Ubuntu Touch, ci si concentra sul caso deiClickPackages, 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 piu veloce di App store, di cui si e parlato nella sezione 2.3.4, haportato con se anche l’adozione di un nuovo sistema di impacchettamento delle applicazioni,

31

denominato ClickPackages. I ClickPackages sono semplici pacchetti di installazione, la cuiprocedura di creazione e notevolmente semplificata attraverso l’uso dell’Ubuntu SDK. Tramitel’Ubuntu SDK e 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 manifestrestano comunque modificabili manualmente. Dopo aver creato il pacchetto, lo sviluppatorepuo firmarne il contenuto utilizzando una propria chiave privata. Tale chiave, insieme allasua corrispondente chiave pubblica, puo essere generata tramite l’Ubuntu SDK. Per la firma siutilizza il tool debsign tra le cui opzioni e possibile speicifcare che la firma e di tipo maint,ovvero si tratta della firma di chi si occupa del mantenimento del pacchetto. Nel caso in cuilo sviluppatore desideri firmare il pacchetto con la propria chiave privata, e necessario che eglipubblichi sul portale Online di Ubuntu, nella sezione relativa al proprio profilo (accessibiletramite 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 ditali 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 tramiteun’apposita pagina web (https://myapps.developer.ubuntu.com) sul portale MyApps, dove allosviluppatore e 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 sonoconsiderati pericolosi, la App e automaticamente approvata. Altrimenti puo essere soggetta aun controllo manuale, in cui alcuni tecnici possono ispezionare il codice sorgente.

Ad applicazione approvata, lo store firma automaticamente a sua volta il pacchetto utilizzandosempre debsign e la propria chiave privata. Questa viene specificato che la firma e di tipoorigin, ovvero dell’entita che si occupa della distribuzione del pacchetto agli utenti. Infine, lostore 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 metadatiche contengono i seguenti campi: un download url che contiene l’url da cui scaricare il clickpackage, e il download sha512 che contiene lo SHA-512 del click package, precalcolato dallostore. Quest’ultimo sara utilizzato dal servizio di download eseguito sul dispositivo per validarel’integrita del pacchetto ricevuto. Si mostra il procedimento nel dettaglio:

• ClickScope19, sul device, richiede allo store online le info di url e hash del pacchetto chevuole scaricare.

• ClickScope chiede al DownloadManager di iniziare il download.

• Il download manager scarica il pacchetto e convalida lo SHA-512 per essere sicuro chenon sia corrotto.

• Il download manager chiede all’install helper di iniziare l’installazione, passandogli ilfile appena scaricato. La comunicazione con l’install helper avviene tramite D-Bus ed emediata da AppArmor.

19ClickScope e 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 sara creato e memorizzato il profiloAppArmor corrispondente ai Policy Groups dichiarati.

Al momento si sta valutando se (e come) concedere in futuro di poter accettare pacchetti firmatisolo 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 ilsistema di confinamento di AppArmor. Al momento per default e vietato l’accesso diretto aquesto servizio da parte delle App confinate. Possono invece accedervi altri servizi come OnlineAccounts. Si pensa che, in futuro, se un’App necessitera dell’uso di Keyring, tale accesso saramediato da Apparmor: quando un’applicazione vorra recuperare delle credenziali, se il profiloAppArmor glielo consentira, sara concesso l’accesso solo alla credenziali salvate da quella stessaapplicazione. Si sta valutando anche se estendere l’integrazione di AppArmor al fine di renderepossibile l’accesso a credenziali che appartengono ad altre applicazioni, permettendolo o diret-tamente nell’AppArmor profile oppure visualizzando all’utente una richiesta di autorizzazione[32].

2.7.2 Credenziali web: Ubuntu online accounts

E un luogo centralizzato per memorizzare le credenziali degli account web. Ogni applicazioneavviata dall’utente puo accedere al database file degli account. Ubuntu Online Accounts eaccessibile tramite D-Bus. L’accesso alle credenziali che esso contiene e protetto, come peraltri servizi, su due livelli distinti (vedi sezione 2.5.5). Un booleano specificato in AppArmorspecifica se tale applicazione puo in generale accedere al servizio Ubuntu Online Accounts.Successivamente e compito di quest’ultimo di gestire i permessi sul singolo account (ovvero aquali degli account memorizzati una certa applicazione puo accedere), e, in caso di necessita, evisualizzato 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 e in grado di proteggere la segretezza dei dati nel caso in cui il dispositivo mobilefosse rubato o in generale si riuscisse a scavalcare le protezioni a livello del sistema operativo. Sinoti che, al contrario, le tecniche di isolamento delle applicazioni discusse precedentemente sonoprotezioni a livello software, il quale progettato in modo da vietare l’accesso non autorizzato adati che pero sono fisicamente memorizzati in chiaro. Cifrando i dati si ha invece protezionea livello fisico, nel senso che abbiamo la “certezza” che se anche un utente malevolo riuscissead avere accesso fisico all’hard disk (ad esempio connettendolo ad un altro computer o piusemplicemente eseguendo il boot con un altro sistema operativo) non sarebbe in grado didecifrarne il contenuto, senza conoscere il segreto che lo protegge.

33

Al momento, le opzioni di cifratura dei dati utente possibili su Ubuntu Desktop, non sonoreplicate nella versione Touch. Ubuntu sta pianificando di portare queste soluzioni anche suidispositivi mobili. Gli sviluppatori hanno confermato che questa funzionalita sara implementatautilizzando il file system crittografico eCryptf, nello stesso modo in cui esso e utilizzato inUbuntu Desktop.

Si tratta di un file system crittografico “stacked”. Il termine stacked indica che esso si disponeal di sopra del file system gia presente, indipendentemente da quale esso sia, e ne proteggei file cifrandone il contenuto e inserendo metadati crittografici nei rispettivi header. Questasoluzione 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 fattoche, sebbene il contenuto dei file sia cifrato, la struttura del file system sia sempre in chiaro. Lasoluzione complementare alla crittografia a livello di file system (file system level encryption) e lafull disk encryption, non disponibile in Ubuntu Touch, che cifra l’intero file system ma, oltre adessere computazionalmente piu dispendiosa, non consente i vantaggi suddetti. Vantaggio dellafull disk encryption e che, cifrando l’intero disco, protegge anche lo spazio di swap20, lasciatoinvece sempre in chiaro da eCryptfs. Questo avviene perche, per questioni di ottimizzazione,lo spazio di swap viene gestito con un particolare file system dedicato gestito direttamente dalkernel. 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, e copiato nellospazio di swap e eCryptfs non ha modo di proteggerlo.

2.8.2 Funzionamento di eCryptfs

Figura 10: Schema di utilizzo delle chiavi in eCryptfs 21.

20Lo spazio di swap e una porzione di hard disk che funge da RAM virtuale, ed e utilizzato quando la memorianon e sufficiente a soddisfare le richieste dei processi in esecuzione.

21Sorgente immagine: [33].

34

Si illustra ora il funzionamento di eCryptfs, con riferimento alla Figura 10. Il sistema di gestionedelle chiavi utilizzato in eCryptfs si ispira alle specifiche OpenPGP (RFC 2440). Cio includela procedura di utilizzare una gerarchia di chiavi nell’eseguire operazioni crittografiche.Il contenuto di ogni file da proteggere e diviso in blocchi da 128 bit e cifrato con AES-128-CBC tramite le Crypto API del kernel Linux. La chiave di cifratura prende il nome di FileEncryption Key (FEC), ed e generata in modo casuale al momento della creazione del file. LaFEC viene poi a sua volta cifrata con un’altra chiave, detta File Encryption Key EncryptionKey (FEKEK), per ottenere la Encrypted File Encryption Key (EFEK). La EFEK viene infinememorizzata all’interno dell’header del file in questione. Resta da capire l’origine della FEKEK.Tale chiave nei dispositivi desktop e ottenuta direttamente dalla password di login. Nel caso didevice 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 e la FEKEK. A questo punto la FEKEK vienememorizzata nel kernel keyring fino al logout dell’utente23. Cio permette di evitare di eseguirepiu volte nel corso della stessa sessione l’algoritmo di hashing suddetto, il quale e volutamente“lento” (1000 o piu 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, eseguitenello 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 e richiesto l’accesso a un file cifrato,eCryptfs recupera nel keyring del kernel la FEKEK, memorizzatavi al login. Questa chiaveviene utilizzata per decifrare la EFEK letta dall’header del file richiesto. La FEK cosı ottenutaviene memorizzata nei metadati di eCryptfs relativi al file in questione e utilizzata per decifrareil contenuto del file [34][35][33].

2.9 Protezione dell’accesso

Come ogni sistema operativo mobile, insieme alle protezioni di basso livello viste precedentemen-te, Ubuntu Touch offre la possibilita di proteggersi dal furto di dati bloccando il dispositivo conuna password alfanumerica da 5 caratteri. La password non viene memorizzata in chiaro bensıviene aggiunto del “sale” e il suo hash con MD5 e salvato in /etc/shadow. Per maggior sicurez-za, sono eseguite 5000 iterazioni della funzione di hash. L’aggiunta di sale e utile ad esempio perdifendersi contro attacchi di tipo dizionario. Il formato di salvataggio prevede una stringa con3 campi separati dal carattere dollaro, ad esempio $1$jQdk4iTA$lanDFksSowpaElsSD, dove icampi 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 altrisistemi di protezione.

22Al momento non si hanno dettagli a come questo sara gestito. E anche possibile che sara considerato comelogin solo il primo accesso dopo l’avvio del dispositivo.

23Anche qui, potra essere lo sblocco o lo spegnimento del dispositivo.

35

2.10 Altri elementi di sicurezza

2.10.1 GSettings/dconf

GSettings e uno strumento per memorizzare le impostazioni di configurazione delle applica-zioni. Sfrutta dconf come back end plugin, con cui i processi comunicano tramite D-Bus perleggere e scrivere le impostazioni dal e sul database. Le applicazioni non confinate possonoleggere e modificare impostazioni per le altre applicazioni. Cio potrebbe voler dire, ad esempio,aggiungere plugin arbitrari che siano eseguiti al caricamento di un’altra applicazione. Anchesolo avere l’accesso in lettura alle impostazioni delle altre applicazioni puo esporre informazionisensibili e causare problemi di privacy.

Dalla versione 13.10 le App confinate non hanno accesso a GSettings. Nonostante si potrebbeutilizzare una protezione di tipo booleano per l’accesso, specificata tramite AppArmor, secondogli sviluppatori non si avrebbe abbastanza sicurezza. In futuro, si legge nella documentazione,si potra permettere alle applicazioni confinate di salvare le loro informazioni in GSettings, macio richiedera una modifica di dconf, in modo tale che sia in grado di tener conto di qualiimpostazioni un’applicazione puo andare a leggere. La mediazione di AppArmor sul D-Busmediera 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 disicurezza che Mir, con l’aiuto delle policy di AppArmor, ha risolto rispetto al precedente XServer.

• Keyboard and mouse sniffing: alle applicazioni eseguite sullo stesso X server eraconcesso eseguire operazioni di sniffing dei tasti premuti e eventi del mouse. Questopoteva permettere ad una applicazione di catturare i dati inseriti in altre applicazioni.

• Screenshot: in X ogni applicazione poteva scattare screenshot anche quando in back-ground. Cio permetterebbe alle applicazioni di catturare dati sensibili mostrati in altreapplicazioni. La progettazione di Mir previene queste azioni (una normale applicazionepuo solo fare lo screenshot del proprio contenuto).

• XSettings: il protocollo XSettings fornisce un meccanismo per far condividere a diverseapplicazioni le stesse impostazioni di interfaccia quali il timeout per il doppio click e i coloridi interfaccia. Il Settings Manager usato in X mantiene una finestra unmapped (unicaper tutti i processi) dove sono memorizzate tutte le impostazioni. Esistono toolkits, comeGTK, che permettono il caricamento di moduli arbitrari specificati tramite XSettings.Cio puo infrangere i confini dell’applicazione.

Il nuovo Mir e progettato contro il keyboard/mouse sniffing. Le applicazioni non hanno lapossibilita di creare tastiere virtuali o sniffare tasti premuti durante l’esecuzione di altre appli-cazioni. Lo scatto di screenshot e proibito quando il focus e su un’altra applicazione. Clipboard,drag and drop e casi speciali come testiere on screen di terze parti sono gestiti attraverso mec-canismi di sicurezza connessi con AppArmor. Questo permette a Mir di, ad esempio, chiederead AppArmor se un’applicazione puo aver accesso alla clipboard. Le applicazioni in fore-ground, di default, hanno accesso alla clipboard di Mir, mentre questo e vietato ai processi non

36

user-facing24. Mir non supporta XSettings a livello di applicazione. In altre parole e possi-bile 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’am-biente prima di essere avviate. Ad esempio, GTK25 permette di specificare moduli arbitrarida 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 chedevono essere eseguiti confinati, in quanto cio potrebbe essere utilizzato per violare i confini.

La soluzione adottata consiste nel cosiddetto Environment scrubbing, ovvero la rimozione divarie 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 adogni altra applicazione in esecuzione, come il segnale TERM che causa la terminazione diun processo. Attualmente, come visto nell’esempio in 2.5.3, il profilo AppArmor deve poterspecificare quali segnali un’applicazione confinata puo 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 protezioneda remoto built-in che consenta di bloccare il dispositivo, localizzarlo o cancellarne i dati.Attualmente e possibile avere questa funzionalita con applicazioni di terze parti come Prey[37]. Tuttavia, l’efficacia di una soluzione basata solo su software e molto discutibile nel nostrocaso. E vero che il sistema puo supportare applicazioni preinstallate che non possono essererimosse dall’utente, tuttavia, se si collega il dispositivo a un computer via USB e si utilizzanogli strumenti di sviluppo di Android, il device puo ad ogni modo essere totalmente resettato. Almomento, dunque, sembra non esserci soluzione lato sistema operativo. Ogni tipo di supportoanti 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/ca-certificates. L’estensione di questi file e .crt, e il formati dei certificati e PEM. Per ragioni disicurezza, a differenza della versione desktop, questa cartella e di sola lettura, dunque non epossibile installare manualmente certificati auto firmati.

24Processi non al momento visualizzati a schermo25GTK+, detto anche GIMP Toolkit, e un toolkit multi piattaforma per la creazione di interfacce utente

grafiche.

37

2.11 Vulnerabilita note

Per Ubuntu Touch si utilizza lo stesso database di CVE utilizzato per Ubuntu. Tale databasemostra le diverse vulnerabilita note, specificandone i livelli di criticita e il package corrisponden-te. E inoltre possibile visualizzare come il livello di criticita sia differente nelle diverse versionidi Ubuntu. Il database e accessibile all’indirizzo: http://people.canonical.com/~ubuntu-

security/cve/.

2.12 Conclusioni

Sebbene possa apparire come un semplice nuovo sistema operativo mobile dall’interfaccia stileUbuntu, si e visto come in realta Ubuntu Touch nasconda una grande innovazione. L’intentodi realizzare una soluzione software congiunta in grado di adattarsi contemporaneamente asmartphone, tablet e desktop ha portato con se la necessita di sviluppare un modello di sicurezzaadatto a tale contesto.

Con piu di 15 anni di storia alle spalle, AppArmor rappresenta uno strumento che ha maturatol’esperienza necessaria per farsi carico di buona parte di questo difficile compito. Si e vistocome il suo funzionamento si basi sulla prevenzione, e non richieda un continuo processo discanning del sistema che minerebbe l’autonomia del dispositivo.

La definizione del confinamento di un’applicazione, gia piu semplice in AppArmor rispetto aaltre soluzioni quali SeLinux, e stata ulteriormente semplificata con i Policy Groups. Affiancan-do a cio un potente SDK, si e riusciti a rendere questo strumento immediatamente accessibileai nuovi sviluppatori.

Dal punto di vista dell’utente, i Trusted Helpers forniscono, tramite messaggi di avviso comeConsentire all’applicazione di accedere alla fotocamera?, massima trasparenza sui permessiconcessi a un’applicazione. Essi permettono inoltre di revocare le autorizzazioni in un secondomomento, opzione non presente in un diffuso sistema come Android.

Il sistema semi automatizzato di revisione delle nuove App consente tempi brevissimi di pub-blicazione di nuovo software e puo essere utile per portare sui device aggiornamenti di sicurezzadelle applicazioni in breve termine. Per essere approvate in automatico, le App devono ri-specchiare requisiti di sicurezza molto restrittivi che ne assicurano l’innocuita nei confronti delsistema: nel caso peggiore, il confinamento garantisce che i danni di un attacco siano limitatial campo di azione della App stessa.

Condividendo con Ubuntu Desktop l’architettura generale, il sistema puo beneficiare dei suoiaggiornamenti di sicurezza.

Infine, trattandosi di un sistema open source, vanta la possibilita di beneficiare del contributo diuna 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, unodegli obiettivi primari dello sviluppo di Ubuntu Touch e incentivare lo sviluppo di applica-zioni, e il modo migliore per riuscirci e renderlo il piu semplice possibile. Questo giustifical’uso dei Policy Groups nei Click packages. Tuttavia, non poter specificare manualmenteun profilo AppArmor per i Click package potrebbe essere in futuro una limitazione. Almomento, infatti, tutti i permessi AppArmor richiesti da un’applicazione devono avereun corrispondente in un Policy Group. Tale modello potrebbe collassare di fronte alla

38

http://people.canonical.com/~ubuntu-security/cve/

http://people.canonical.com/~ubuntu-security/cve/

necessita di avere un modello di sicurezza piu complesso che permetta di definire il con-finamento con piu dettaglio. Naturalmente, si perderebbe il vantaggio di una revisioneautomatica dell’applicazione da parte dello store. Per questo, una soluzione potrebbe es-sere concedere la possibilita allo sviluppatore di definire profili AppArmor manuali per ipropri Click package a patto che essi siano revisionati manualmente, eventualmente sottopagamento di una commissione.

• Al momento il confinamento delle applicazioni e fatto su due livelli: AppArmor e TrustedHelper. Nel momento in cui un Trusted Helper memorizza un certo permesso concessodall’utente, l’applicazione in questione puo accedere (da lı in avanti) a una determina-ta risorsa prima proibita. In tutto cio, il profilo AppArmor e rimasto invariato. Essosemplicemente dichiara la possibilita per quell’applicazione di comunicare con lo specifi-co Trusted Helper, ma non contiene informazioni riguardo la scelta dell’utente. Questomeccanismo fa si che il profilo AppArmor non sia sufficiente per determinare i privilegidi un’applicazione. Sarebbe meglio che tali informazioni fossero concentrate in un unicopunto. Ad esempio si potrebbe estendere AppArmor al fine di memorizzare in un profiloanche le definitive autorizzazioni concesse dell’utente. In tal caso dovrebbe essere capacedi modificare dinamicamente il profilo in funzione di esse.

• Al fine di non impattare l’autonomia del dispositivo, non e presente un sistema di mo-nitoring costante delle risorse utilizzate dai processi. Inoltre, condividendo l’architetturacon Ubuntu desktop, non si ha ancora un sistema di gestione ottimizzata dei proces-si in background: in altre parole, come su Ubuntu Desktop, e concessa l’esecuzione inbackground senza limitazione di risorse. In questo modo un’applicazione intenzionata asaturare le risorse del dispositivo in termini di CPU o a scaricare la batteria, potrebbesuperare automaticamente i controlli di sicurezza dello store e portare a termine il suoscopo.

39

3 CyanogenMod

Figura 11: Schermata di home di CyanogenMod 26.


In questo capitolo verranno analizzati alcuni aspetti di sicurezza di CyanogenMod. Si trattadi una Mod di Android, il diffuso sistema operativo di Google. Il termine “Mod” significache si tratta di una nuova versione dello stesso software, con alcune modifiche che permettonomaggiore personalizzazione e funzionalita aggiuntive. Per questo motivo, saranno analizzati inparticolare gli aspetti che lo distinguono da Android e che si trovano principalmente a livello diapplicazione. Si e deciso di non analizzare la sicurezza di basso livello in quanto essa coincidecon quella di Android ed esula pertanto dagli scopi di questo report. Le informazioni quiriportate provengono in gran parte da ricerche online anche al di fuori della Wiki ufficiale.CyanogenMod conta molto sull’informazione generata e trasportata dalla community, pertantola documentazione “ufficiale” e molto scarsa. Al fine di accertare le informazioni trovate, sonostate effettuate prove manuali su dispositivi reali.

26Sorgente immagine: http://crysweb.altervista.org/2015/02/19/android-lollipop-su-oneplus-one-con-cyanogenmod-12/.

40

3.2 Introduzione

3.2.1 Storia

Poco dopo il rilascio del telefono cellulare HTC Dream (conosciuto come “T Mobile G1” negliStati Uniti) nel settembre 2008, fu scoperto un sistema per ottenere un controllo di ammini-strazione (conosciuto come “accesso root”) al sistema Linux sul quale si basa Android. Averel’accesso root, combinato alla natura open source del sistema operativo Android, ha permessoal firmware originale del telefono di essere modificato e re-installato sul telefono stesso. Ne-gli anni successivi molti firmware modificati furono sviluppati e distribuiti da appassionati diAndroid. Uno, mantenuto da uno sviluppatore chiamato JesusFreke, presto divento popolaretra i possessori del Dream. Nell’agosto 2009 JesusFreke smise di lavorare al suo firmware esuggerı agli utenti di passare a una versione della sua ROM che era stata ulteriormente miglio-rata dallo sviluppatore Cyanogen (Steve Kondik), chiamata “CyanogenMod”. La popolaritadi CyanogenMod crebbe rapidamente e una piccola comunita di sviluppatori, conosciuta comeCyanogenMod Team, contribuı al progetto. Nel giro di pochi mesi il numero di dispositivi edi funzionalita supportate da CyanogenMod aumento e CyanogenMod divento in poco tempouna delle distribuzioni di firmware Android piu popolari [38].

3.2.2 Differenze con Android

CyanogenMod offre caratteristiche e opzioni non disponibili nel firmware ufficiale distribuitodai 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 altriancora. Se queste caratteristiche fanno pensare semplicemente a un sistema operativo che offreall’utente piu funzioni e maggiore personalizzazione, si sottolinea anche che la progettazionedi CyanogenMod e volta a migliorare le performance, affidabilita e sicurezza dei dispositivi.Come vedremo successivamente, queste caratteristiche positive portano con se un rovescio dellamedaglia. Fornire maggiori funzionalita all’utente significa anche dargli maggiori permessie, potremmo dire, maggior fiducia. Un utente inesperto potrebbe inconsciamente minare lasicurezza del proprio dispositivo, molto piu facilmente che su sistemi piu “chiusi” quali adesempio iOS [39].

3.2.3 Distribuzione

Secondo le nostre informazioni, al momento CM e distribuito come sistema operativo nativosolo sullo smartphone OnePlus One. Per gli altri dispositivi, e da intendersi come un sistemaoperativo installabile in sostituzione di quello gia presente. Il 6 Gennaio 2015 e stata rilasciatal’ultima versione: CyanogenMod 12. Il firmware e rilasciato in diverse varianti: Stable, ReleaseCandidate e Nightlies. La versione Stable, come lo stesso nome suggerisce, e quella maggior-mente testata, conforme agli standard (informali) di sicurezza e stabilita che la comunita deglisviluppatori si impone. Release Candidate e la fase subito precedente alla Stable: si tratta diuna versione che non presenta bug o vulnerabilita fatali, ma che non e ancora stata testatacompletamente. Infine, le Nightlies sono piccoli aggiornamenti molto poco testati, rilasciati adistanza di poche ore l’uno dall’altro, e per questo motivo sconsigliati all’utente medio [40].

27Free Lossless Audio Codec e 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 sistemaLinux o suo derivato, come Android. Il superuser possiede privilegi di amministratore, pertantoe in grado di accedere ad ogni dato all’interno del sistema e di eseguire operazioni potenzialmentepericolose per la stabilita e sicurezza del sistema stesso. I sistemi Linux desktop permettonodi ottenere privilegi di amministratore semplicemente attraverso la shell. La maggior parte deisistemi operativi mobili Linux-based, essendo progettati per un’ampia utenza di competenzamedio-bassa e facendosi carico delle problematiche di sicurezza trattate nell’introduzione diquesto report, adottano invece una strategia piu restrittiva, in cui all’utente sono fortementelimitate operazioni sensibili sul sistema. Il root (o rooting) viene spesse eseguito con lo scopodi superare queste limitazioni, imposte generalmente dagli operatori telefonici o dal produttoredell’hardware. Il rooting da l’abilita (o il permesso) di modificare o sostituire applicazionipreinstallate e impostazioni di sistema, avviare particolari applicazioni che richiedono permessidi amministratore, avere accesso di basso livello all’hardware, o eseguire altre operazioni chesono di norma inaccessibili a un normale utente Android [41].

Come ogni Mod che si rispetti, e al fine di rendere possibili molte delle caratteristiche vantag-giose che lo contraddistinguono dallo standard Android, CyanogenMod e in grado di fornireall’utente e alle applicazioni privilegi di amministratore (privilegi di root). Come gia accennato,ai vantaggi suddetti si affiancano diversi svantaggi: ottenere accesso root significa anche poteraggirare le restrizioni di sicurezza standard del sistema operativo. Il che significa che worms,virus, spyware e trojan possono infettare il dispositivo, se non e protetto in altro modo (lovedremo nella sezione 3.3.3). Ci sono diversi modi tramite cui questi malware possono infettareil proprio telefono o tablet: web downloads, link malevoli, applicazioni infette scaricate da altriapp store. Software malevolo eseguito con privilegi di amministratore puo avere accesso ad ognidato contenuto nel dispositivo.


3.3.1 Il modello Android

Il modello di sicurezza di CyanogenMod realizza il confinamento delle applicazioni allo stessomodo di Android, riutilizzando il sistema nativo del Linux Kernel di gestione dei permessiutente. Nei sistemi Linux desktop, ad ogni utente e associato un identificativo univoco (UID- User Id) che e poi utilizzato per specificare i permessi di accesso a file e cartelle: ogni filee 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 comeutenti e assegnando a ognuna di esse un diverso UID. In questo modo, ogni applicazione puoaccedere solamente ai file di sua proprieta, o eventualmente alle risorse di altre applicazioniper cui e stato esplicitamente consentito l’accesso. Come gia detto, poiche l’analisi di Androidesula dagli scopi di questo report, non si scende nei dettagli implementativi di questa soluzione.Per una discussione piu approfondita si rimanda a [42]. L’autorizzazione ad utilizzare risorsequali GPS, Fotocamera, Contatti, Risorse ecc... viene richiesta al momento dell’installazione:l’utente puo visualizzare l’elenco dei privilegi richiesti e decidere se accettarli e proseguirecon l’installazione, oppure rifiutarli e annullare. Android non presenta ad oggi una soluzioneper concedere all’utente di personalizzare i permessi di una applicazione o rimuovere specificiprivilegi concessi al momento dell’installazione.

42

Figura 12: Schermata di esempio di Privacy Guard 28.

3.3.2 Gestione dei permessi

CyanogenMod, pur condividendo con Android la soluzione basata sugli UID per il confinamentodelle applicazioni, offre una funzione in grado di permettere all’utente di revocare selettivamentead una applicazione i permessi concessi al momento dell’installazione. Tale funzione e realizzatatramite l’applicazione built-in Privacy Guard. Privacy Guard e presente in CM a partire dallaversione 10 e, oltre a quanto detto, consente anche di selezionare quali applicazioni debbanoessere avviate automaticamente al bootup del dispositivo. E stata realizzata con l’intento diportare la gestione della privacy anche nelle mani dei meno esperti, pertanto, oltre ad unmenu avanzato per ogni applicazione, fornisce anche la possibilita di semplicemente attivare odisattivare il profilo Privacy Guard per una specifica App, impostando un profilo di sicurezzadi default [43].

Privacy Guard e stato realizzato sulla base di App Ops. App Ops era una funzionalita giapresente in versioni precedenti e nascosta, scoperta per la prima volta in Android 4.3. Il suoscopo era quello di permettere agli utenti di disabilitare specifici permessi alle applicazioni dopol’installazione. In realta App Ops non fu mai pensato come uno strumento per gli utenti, masolo per scopi di debugging [44]. E stato rimosso nelle build di Android successive alla 4.3.Privacy Guard e ora l’“App Ops” di CyanogenMod a partire dalla versione 10 [45]. Non e daescludere che gli sviluppatori di CM possano aver riutilizzato parte del codice della vecchia AppOps di Google, forse avendone anche a disposizione il sorgente intero.

CyanogenMod ha dunque integrato App Ops in modo che gli utenti possano individualmenteimpostare su on o off i permessi per la localizzazione, la lettura dei contatti e dei log dellechiamate, la lettura del calendario, permessi su SMS/MMS ecc... per ciascuna app installata.E stata aggiunta anche la possibilita di ricevere notifiche nel momento in cui una App tenta diaccedere ad una risorsa bloccata. L’ultimo accesso consentito viene memorizzato e puo esserevisualizzato. Poiche la rimozione dei permessi ad una applicazione non e normalmente possibile,tale operazione potrebbe minare la stabilita dell’applicazione interessata.

28Sorgente immagine: http://androidcommunity.com/cyanogenmod-privacy-guard-updated-and-merged-with-cm10-2-20130925/.

43

3.3.3 Gestione privilegi di root

In passato, per poter utilizzare CyanogenMod, era necessario provvedere manualmente alla suainstallazione su un dispositivo supportato, al posto del precedente sistema operativo Android.Eseguire questa operazione richiedeva competenze non comuni e rappresentava pertanto unadifficolta in grado di selezionare l’utenza di CM. A seguito di cio, CM era utilizzato prevalen-temente da individui mediamente coscienti dei rischi legati alle nuove potenzialita fornite dalsistema operativo e, in generale, all’uso di un device rooted. Ad oggi, invece, eseguire il rootinge molto piu semplice, grazie all’uso di tool appositi e ad una vastissima documentazione in rete.Cio ha reso questa Mod di Android alla portata di una gamma di utenti sempre piu vasta.Inoltre, come gia accennato in precedenza, proprio in questi mesi si sta assistendo all’arrivo sulmercato dei primi dispositivi venduti con CM gia installato. Cio fa capire come CM non sia piuconsiderabile 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 sfruttareper provare funzionalita normalmente vietate.

Per queste ragioni, la 11 e l’ultima versione di CM ad essere rooted di default. In CM11 inteoria tutte le applicazioni possono eseguire operazioni con privilegi di root. In pratica, lasicurezza viene implementata a livello di applicazione: applicazioni di terze parti, tra le qualispicca Superuser, si occupano di permettere all’utente di gestire quali applicazioni possanoottenere i privilegi di amministratore. A partire da CM12, invece, di default il device non erooted. L’arricchimento delle API fornite dal sistema operativo rispetto ad Android e in gradodi permettere a molte applicazioni di fornire nuove funzionalita pur non avendo bisogno deiprivilegi di root [46].

Tuttavia, in CM12 e comunque possibile abilitare il root del dispositivo. E curioso notare come,al fine di evitare che un utente attivi inconsciamente il root, tale opzione sia stata nascosta: enecessario recarsi in “Settings”-¿“About phone” e toccare “Build number” piu volte29. Il rootpuo essere attivato in 3 modalita distinte:

• Solo per le App;

• Solo per l’ADB30;

• Per entrambi.

Una volta che il root per le App e attivato, all’interno delle impostazioni di Privacy Guard perciascuna applicazione, apparira una nuova opzione che, come Superuser in CM11, permetteradi dare singolarmente a ciascuna applicazione il permesso di eseguire azioni con privilegi diroot.

Privacy Guard e in grado di intercettare le richieste delle applicazioni di eseguire il comandosu, 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 possibilita di autorizzareo meno l’operazione. Per vedere questo meccanismo piu nel dettaglio, si consideri il caso diun’applicazione che esegue la seguente riga di codice:

Process p = Runtime.getRuntime().exec(‘‘su’’);

29Le ragioni di questa scelta risiedono con ogni probabilita nel fatto che per scoprire tale funzionalita enecessaria una ricerca in rete, che presume un minimo livello di informazione al riguardo

30Android Debug Bridge, e uno strumento a riga di comando per sistemi desktop che permette di comunicarecon un dispositivo android connesso.

44

Tale riga causa la pubblicazione di un Intent31, all’interno del gestore dei messaggi di Android,che richiede a Privacy Guard di confermare o meno l’operazione. La scelta dell’utente vienesalvata per i futuri utilizzi e resta modificabile attraverso il pannello di controllo di PrivacyGuard.

3.4 Store

Poiche CyanogenMod sfrutta lo stesso App store di Android, Google Play, non tratteremo indettaglio le sue caratteristiche di sicurezza. Google Play prevede che le applicazioni siano fir-mate dagli sviluppatori e sottoposte a un processo di revisione in parte manuale e in parteautomatico. E importante sottolineare che, nel caso di CyanogenMod, la sicurezza a livellodi store non ha grande effetto sulla sicurezza finale del dispositivo. Infatti, una delle funzio-nalita piu utilizzate degli utilizzatori di questo sistema operativo e la possibilita di installareapplicazioni da fonti diverse dallo store “ufficiale”. Tali applicazioni spesso richiedono privilegispeciali (di root) per fornire quelle funzionalita aggiuntive che l’utente medio di CyanogenModdesidera. Del resto, come detto nell’introduzione, questo e il concetto base attorno a cui ruotaquesto sistema operativo. Per questo motivo, la sicurezza e molto piu nelle mani dell’utente,che deve gestire manualmente privilegi speciali, piuttosto che nei meccanismi attuati a livellodi store.

3.5 Componenti di sicurezza aggiuntivi

3.5.1 Whisperpush

Gli sviluppatori di CyanogenMod hanno lavorato per lungo tempo all’integrazione nel propriofirmware di un servizio di messaggistica sicura, fino a riuscire ad introdurlo per la prima voltaufficialmente in CM11. Si chiama Whisperpush e si basa su TextSecure, un client open-sourcecross-platform (iOS e Android) che cifra gli SMS sia localmente che durante l’invio ad altriutenti TextSecure. Questa funzionalita, sul modello di iMessage utilizzato nei sistemi iOS, unavolta abilitata e totalmente trasparente all’utente. Nel momento in cui si invia un messaggioattraverso l’applicazione nativa per gli SMS, il sistema controlla se il destinatario possiede unclient TextSecure (sia esso un dispositivo Android o iOS) e, in caso affermativo, provvede allacifratura del messaggio e al suo invio attraverso il canale dati, altrimenti esso viene inviatocome normale SMS. Il dispositivo che riceve il messaggio cifrato provvedera alla sua decifraturae a mostrarlo all’interno dell’applicazione nativa per gli SMS. Tutto cio e totalmente nascostoall’utente, a cui non e richiesto di eseguire uno scambio di chiavi, o di sapere che il ricevente e“online”.

Il protocollo TextSecure nasce come una modifica del protocollo OTR (off the record messagingprotocol), che usa chiavi effimere concordate tramite l’algoritmo Diffie-Hellman a curva ellittica.L’utilizzo di chiavi effimere e utile perche usare sempre la stessa chiave pubblica puo nel tempoaumenta la probabilita che sia scoperta. In tal caso, sarebbe inoltre possibile decifrare tuttii messaggi inviati precedentemente con chiunque. La modifica del protocollo OTR e statanecessaria per adattarlo ad un ambiente mobile, dove fattori come lo stato della rete e i vincolilegati al risparmio energetico richiedono che la messaggistica sia di natura asincrona. In sostanzasi e dovuto gestire il caso in cui la controparte non sia al momento raggiungibile (vuoi perchenon ci sia copertura di rete o perche il sistema operativo non gli permetta di essere eseguita in

31Un Intent e un oggetto di messaggistica che puo essere utilizzato per richiedere un’azione a un’altraapplicazione.

45

background). Poiche Diffie-Hellman richiede ovviamente uno scambio di messaggi, per adattarloa questo contesto asincrono e stata utilizzata la soluzione che e descritta di seguito.

Dettagli del funzionamento del protocollo TextSecure:

1. Alla prima connessione al server, un client TextSecure, che si vuole chiamare A, generapreventivamente 100 messaggi per lo scambio chiavi Diffie-Hellman e li invia al server. Sichiamino questi “premessaggi”. La curva ellittica utilizzata e Curve25519.

2. Un nuovo client B, che vuole inviare ad A un messaggio sicuro, puo ora connettersi alserver 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 puo utilizzare per inviare al serveril messaggio cifrato, insieme ai propri messaggi per il key agreement. I messaggi sonocifrati utilizzando un cifrario AES in modalita CTR, con una chiave a 256 bit. Il server,non essendo a conoscenza del segreto di A utilizzato per generare i premessaggi, non e ingrado di decifrare il messaggio.

4. Nel momento in cui A si colleghera al server potra 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 DeviceManager”. Si tratta di un servizio online che da la possibilita agli utenti di eseguire da remotooperazioni sul proprio device, principalmente a scopi di sicurezza. E possibile ad esempio bloc-care il proprio device con una nuova password, oppure eseguirne il wipe, ovvero la cancellazionedi tutti i dati contenuti. Android device Manager consente inoltre di rintracciare il propriodispositivo, se dotato di GPS.

Gli sviluppatori di CyanogenMod hanno risposto alla soluzioni di Google con “Device Finder”.Dal punto di vista delle funzionalita offerte si tratta di un servizio del tutto simile all’AndroidDevice Manager, ma che presenta grandi differenze nella sua implementazione, volte a garantiremassima sicurezza e riservatezza agli utenti [47].

Quando si utilizza Android Device Manager per rintracciare il proprio dispositivo, e necessarioautenticarsi 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 interrogareil proprio smartphone riguardo la propria posizione. Il server Google rintraccia il dispositivograzie a un servizio, Google Play Services, che opera silenziosamente su di esso. Il nostrodevice Android e progettato per fidarsi del server Google, pertanto risponde inviando la propriaposizione. Infine, il server Google passa questa posizione al nostro browser, dove e possibilevisualizzarla.

Come si puo notare, il server Google agisce da intermediario. Esso vede le informazioni tra-smesse in chiaro. Teoricamente potrebbe personificare una persona e chiedere al nostro devicela sua posizione in qualsiasi momento lo desideri. Potrebbe essere che qualcuno al di fuoridel proprietario utilizzi il server Google per avere la nostra posizione, magari in seguito adaccordi commerciali. Ovviamente e noto che Google promette di non rivelare le nostre infor-mazioni, ma in questo modo la nostra sicurezza consiste appunto nel fidarsi di Google, e nonnell’implementazione del sistema stesso [48].

Il servizio CyanogenMod Device Finder disponibile all’interno di CyanogenMod Accounts creainvece un canale di comunicazione sicuro tra il browser e il dispositivo, in cui il server svolge solo

46

www.google.com/android/devicemanager

www.google.com/android/devicemanager

Figura 13: Confronto tra il reperimento della localizzazione del dispositivo tramite l’AndroidDevice 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, neviene inviata una sua derivata.

2. Nel momento in cui viene richiesta la posizione del device, il browser genera una coppiachiave 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 mes-saggio 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 e in grado di leggere lachiave simmetrica contenuta all’interno del messaggio cifrato in quanto non e in possessodella chiave privata per decifrarlo.

6. Il nostro browser, che invece conosce la chiave privata ottenuta nel passaggio 2, decifra ilmessaggio e ottiene la chiave simmetrica.

7. Da questo momento in avanti, browser e device possono comunicare attraverso un canalesicuro protetto con tale chiave asimmetrica. Il server fara sempre da intermediario, manon potra decifrare i contenuti in transito.

La sicurezza di questo sistema consiste nella sua implementazione, non nella fiducia versoqualcuno o qualcosa. Quando il nostro dispositivo invia la propria posizione, nessun agente nelmezzo puo leggerla. Nessuno puo iniziare il rintracciamento se non il proprietario. Nessuno

47

puo pagare o accordarsi con gli operatori del server affinche rintraccino il dispositivo senza ilnostro consenso.

Si ricorda che aziende come Google e Apple, se da una parte vogliono vendere i propri prodotticome sicuri per attirare gli utenti, dall’altra hanno interessi a non proteggere la loro privacy.Questo tipo di interesse non e invece riscontrabile in CyanogenMod, non essendo un prodottoa scopo di lucro.

3.6 Cifratura dati utente

La cifratura e utilizzata per garantire la riservatezza dei dati memorizzati su un dispositivo incaso della perdita o furto dello stesso.

In CyanogenogenMod, le possibilita di cifratura offerte sono ereditate da Android. In questo,la cifratura per proteggere i dati e disponibile soltanto dalla versione 3.0 (Honeycomb) in su.Per abilitare la cifratura su un dispositivo Android il filesystem deve essere montato su undispositivo che presenta un interfaccia block device32. La cifratura e effettuata con dm-crypte, sebbene si parli di disk encryption, in realta non e eseguita sull’intero disco (in quantorenderebbe impossibile il boot) ma solo sulla cartelladata, contenente tutti i dati utente e delle applicazioni.

Dm-crypt e un sistema per la crittografia dei dati utilizzato nel Kernel linux a partire dallaversione 2.6. Esso e parte dell’infrastruttura “device mapper”, ovvero quella che si occupa dellamappatura dei dati tra unita virtuali di archiviazione di massa (come viste e utilizzate dalleapplicazioni) e effettivo hard disk fisico. La crittografia dei dati avviene in modo trasparenteal resto del sistema proprio nel corso di questa mappatura [50]. Una volta che il disco e cifrato,ogni dato creato dalle applicazioni viene automaticamente cifrato prima che sia scritto su diesso e tutti i dati letti da disco sono automaticamente decifrati prima di essere ritornati alprocesso che li richiede.

Dm-crypt utilizza AES-128 con CBC e ESSIV SHA 256 33. La chiave di cifratura e memorizzatasul disco in modo sicuro secondo un processo che coinvolge sia la password dell’utente siauna chiave memorizzata in hardware nel dispositivo (hardware-bound private key, HBK)34. Simostra tale processo nel dettaglio:

1. In modo casuale viene generata una disk encryption key (DEK) di 128 bit e un sale dellastessa lunghezza. Questa prima fase e eseguita solo la prima volta che si attiva la cifraturadel disco.

2. Si applica scrypt35 alla password dell’utente e al sale della fase precedente per produrreuna chiave intermedia IK1 di 256 bit.

32Un dispositivo a blocchi (in lingua inglese block device), nei sistemi operativi Unix e Unix-like, e un dispo-sitivo su cui e possibile effettuare operazioni di input/output per blocchi di byte di dimensione predeterminata(tipicamente dispositivi di memoria di massa come i dischi rigidi).[49]

33ESSIV e un metodo per generare vettori di inizializzazione per cifratura a blocchi utilizzata nella cifraturadi dischi di memoria. ESSIV genera i vettori di inizializzazione da una combinazione del numero di settore deldisco da cifrare e l’hash della chiave di cifratura [51].

34Parliamo di una TEE key. TEE e acronimo di Trusted Execution Environment ed e una area sicura delprocessore di un dispositivo che fornisce funzionalita di sicurezza

35Scrypt e una key derivation function. Come PBKDF2, gia vista in 2.8, serve per derivare un segreto, nelnostro caso IK1 e IK3, a partire da un altro segreto, nel nostro caso la password dell’utente e IK2. A differenzadi PBKDF2, scrypt e piu sicura contro attacchi brute-force implementati in hardware.

48

3. A IK1 viene aggiunto del padding per portarlo alla lunghezza della HBK citata preceden-temente.

4. Il risultato dell’operazione precedente e firmato utilizzando HBK per produrre IK2, di256 byte.

5. Si applica nuovamente scrypt a IK2 utilizzando lo stessso sale della fase 2 per produrreIK3, di 256 bit.

6. I primi 128 bit di IK3 sono utilizzati come KEK (key encryption key) e gli ultimi 128come 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 ulterioreprotezione contro attacchi “off the box” in cui l’hard disk e estratto dal dispositivo.

Il lettore potrebbe chiedersi perche la DEK sia generata in modo casuale invece che direttamentederivata dalla password utente. La risposta risiede nel fatto che se cosı fosse fatto, cambiare lapassword utente richiederebbe di decifrare e ricifrare con la nuova DEK corrispondente tutti idati gia cifrati. Nel modo sopra illustrato, al contrario, e sufficiente decifrare la DEK e ricifrarlacon la nuova KEK [52].


Figura 14: Esempio di Lock Pattern 36.

Il controllo di accesso tradizionale consiste in una sistema di sicurezza che consente l’accesso aldispositivo solo a chi conosce un segreto preimpostato. Tale segreto, richiesto per sbloccare ildispositivo dalla condizione di standby, puo essere in forma di:

36Sorgente immagine http://automagic4android.com/.

49

• Lock Pattern. Si tratta di uno specifico percorso su una griglia di punti 3 X 337. Losvantaggio e che se il display trattiene facilmente le impronte lasciate dalle dita, potrebbeessere facile recuperare il percorso. Si consigliano pertanto percorsi non troppo semplici.E mostrato in Figura 14.

• Codice PIN. E una sequenza di cifre. Il numero di cifre va da 4 a 17.

• Password alfanumerica. E la password classica alfanumerica. E sicuramente il sistemapiu sicuro, ma richiede generalmente piu tempo per l’inserimento.

3.8 Conclusioni

In origine, CyanogenMod rappresentava un sistema operativo accessibile ad un’utenza relati-vamente esperta. Cio ha permesso per anni di trascurare alcune problematiche di sicurezza,secondo un modello di fiducia verso l’utente. Indubbiamente si trattava di un sistema piu pe-ricoloso (si pensi al root abilitato di default), ma cio era in un certo senso il prezzo da pagareper poter usufruire di certe potenzialita.

La sua recente crescente diffusione, unita a un diffuso innalzamento degli standard di sicurez-za richiesti dal mercato, hanno portato gli sviluppatori ad ideare una soluzione in grado alcontempo di soddisfare la necessita di un sistema sicuro e le richieste di quella grossa fettadi utenza amante del root. L’integrazione di superuser all’interno di Privacy Guard, insiemead un’impostazione di default che disabilita il root, rendono il sistema operativo utilizzabile inmodo sicuro anche dai meno esperti. Il sistema messo in pratica da Privacy Guard era divenutoparticolarmente necessario da quando, sapendo dell’incoscienza dell’utente medio nell’installareapplicazioni non fidate, tra gli sviluppatori e diventato di uso comune richiedere per la propriaapp un lungo elenco di autorizzazioni. si trova infatti oggi sul Google Play Store applicazioni co-me la torcia, che richiedono il permesso di accedere ai nostri contatti o al profilo Facebook, e cionon sembra importare molto agli utenti. Cio fa riflettere su quanto sia importante l’educazionedel pubblico alla sicurezza e su quanto ci sia ancora molto da fare.

Nel complesso, e possibile notare un grande passo avanti rispetto ad Android: la possibilita digestire in modo semplice ed intuitivo le singole risorse a cui le applicazioni possono accedere euna pietra miliare nel cammino verso un sistema sempre piu attento alla privacy degli utenti.Purtroppo, poiche le applicazioni scaricabili su un dispositivo CyanogenMod sono le stessesviluppate per Android, esse non prevedono che i permessi possano essere revocati. In tal caso,la stabilita dell’App e fortemente compromessa.

E importante sottolineare che l’intero codice di CyanogenMod e Open Source, scaricabile ecompilabile. Nonostante i piu non abbiano le competenze per comprenderlo, cio e un aspettoimportantissimo in termini di sicurezza. Avere accesso al codice consente alla comunita disviluppatori di setacciarlo alla ricerca di problemi da risolvere. Qualcuno potrebbe obiettareche il codice open source e un’arma a doppio taglio: di fatto e vero, trovare falle di sicurezzapotrebbe anche consentire ad un attaccante di sfruttarle per scopi maligni. Tuttavia, si ricordache il codice dei nuovi moduli viene pubblicato nelle nightly build ben prima che sia inseritoall’interno delle stable release. In questo lasso di tempo, e probabile che eventuali vulnerabilitasiano scoperte. Per queste ragioni e consigliabile di installare solo le versioni stable.

Se da questo punto di vista le nightly build possono essere meno sicure in quanto non ancoratestate a sufficienza, dall’altro rappresentano un potente strumento per migliorare la sicurezza:tramite queste, infatti, gli sviluppatori possono fornire agli utenti aggiornamenti rapidi controeventuali nuove vulnerabilita scoperte.

37In alcune versioni e possibile modificare la dimensione della griglia

50

4 Tizen

Figura 15: Schermata Home di Tizen38


L’analisi di sicurezza di Tizen e la combinazione di un’analisi documentale e sperimentale.Sebbene la prima sia quella di maggiore consistenza, tramite alcuni test sperimentali e statopossibile comprendere al meglio le tecniche impiegate nel sistema. Tizen attualmente vieneinstallato solo in alcuni dispositivi venduti nel mercato asiatico, per questo e stato possibileeseguire i test solo nella versione virtualizzata del sistema operativo.

Lo sviluppo di Tizen e recente, ma la documentazione disponibile e ampia, soprattutto quellaa disposizione per gli sviluppatori39 ed il Wiki40. Tuttavia le informazioni appaiono spessoframmentarie ed e evidente la necessita di riorganizzazione. La continua evoluzione e le nuovesoluzioni proposte rendono spesso difficile il compito di analisi.

Nella ricerca di informazioni hanno rivestito grande importanza anche mailing list ufficiale edil materiale reso disponibile in occasione delle “Tizen Developer Conference”, sia nella forma

38Sorgente immagine: https://en.wikipedia.org/wiki/Tizen#/media/File:Tizen screenshot en original.png39https://developer.tizen.org/documentation40https://wiki.tizen.org/wiki/Main Page

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 deicomponenti di sicurezza del sistema operativo.

L’analisi segue lo schema logico definito in 1.3. Da notare che le sezioni su “Tecniche diconfinamento delle applicazioni” 4.5 e “Componenti di sicurezza aggiuntivi” 4.9 prevedonoalcuni paragrafi di commento da parte dell’autore del report. Inoltre, le tematiche riportatein “WebGL” 4.6.2 e “XSS” 4.6.3 non trovano completo riferimento in fonti esistenti, ma sonofrutto di un processo di analisi critica delle soluzioni adottate. La sezione 4.12, invece, ecompletamente dedicata all’esposizione dei risultati sperimentali.

4.2 Introduzione

Tizen e 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 piattaformaopen source per tutti i dispositivi dell’elettronica di consumo (netbook, TV, macchina fotogra-fica, stampante, lavatrice). Per poter gestire la diversita dei sistemi supportati, Tizen utilizzaprofili dedicati: configurazioni specifiche dello stesso sistemi operativo. L’analisi si concentrasul 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 applicazio-ni, per quanto simili nelle funzionalita, differivano nell’usabilita. I produttori dei dispositivisviluppavano piattaforme proprietarie e specifiche per ciascun apparecchio. Oggi nel mondodell’“Internet of the Things”, le esigenze di connettivita, compatibilita ed usabilita richiedonoun cambiamento nell’approccio allo sviluppo. Qui nasce l’idea alla base di Tizen: una piatta-forma standard, utilizzabile in diverse categorie di dispositivi con pochi cambiamenti. Inoltre,essendo open source, i produttori possono sviluppare con maggiore semplicita.

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 sullosviluppo di Windows Phone. Intel era ancora intenzionata a sviluppare un sistema operativoottimizzato per i propri processori, con l’intenzione di entrare nel crescente mercato mobile. Nel2011, con il supporto della Linux Foundation, nasce Tizen. Contemporaneamente, Samsungera alla ricerca di un nuovo sistema operativo per i propri prodotti, con il principale obiettivodi diminuire la propria dipendenza da Android. Samsung si unı al progetto, portando con sesoluzioni 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 puntodi incontro per le aziende, un’occasione per poter prendere parte alle decisioni sul futuro dellapiattaforma. Attualmente lo sviluppo del software e principalmente diretto da Samsung e Intel.

41https://download.tizen.org/misc/media/42http://www.tizenassociation.org

52

La versione 1.0 di Tizen, Larkspur, viene rilasciata nell’Aprile del 2012. In Figura 15 vienepresentata un’anteprima della schermata di home della nuova versione 3.0, attualmente ancorain 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’ul-tima solo dalla versione 3.0 di Tizen.

4.2.4 Le applicazioni

Il package e l’entita di installazione in Tizen ed e un contenitore di applicazioni. Viene identifi-cato in modo univoco tramite il PackageId. Ciascuna applicazione ha associato un identificativoglobalmente univoco, l’AppId ed un AppName. Tutte le applicazioni del pacchetto condividonole 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 perfor-mance e per il limitato consumo di memoria, inoltre vi e un ampia disponibilita di librerieesistenti.

• Web, scritte in HTML, CSS e Javascript, i linguaggi del Web. Lo sviluppo e semplice, lacompatibilita e massima. Possono anche essere installate ed eseguite quando il dispositivoe offline, ma non supportano l’esecuzione in background.

Dalla versione 3.0, Tizen aggiunge il supporto per le applicazioni Ibride [56]. Combinano lasemplicita dell’applicazione web con la potenza di calcolo di uno o piu servizi scritti in linguaggionativo. Permettono un rapido sviluppo dell’interfaccia, tramite HTML5 e CSS3, ed un efficaceprocessamento dei dati in background grazie alla vasta disponibilita di librerie native.

Il packaging delle applicazioni Web segue le specifiche W3C43:

• Il formato del file e un archivio ZIP.

• L’estensione del file e .wgt.

• MIME type: application/widget.

Il packaging delle applicazioni Native ed Ibride segue invece le seguenti specifiche:

• Il formato del file e un archivio ZIP.

• L’estensione del file e .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 sistemapossa essere utilizzato da un solo utente alla volta, piu utenti possono essere registrati, ciascunocon i propri dati e le proprie applicazioni.

43World Wide Web Consortium (W3C)

53

4.2.5 Strumenti di sviluppo

Esistono versioni specifiche del Software Development Kit (SDK) per i profili Mobile, Wearablee 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 lostrumento di debug. Permette eseguire una shell Unix da remoto, la sincronizzazione dei file ela gestione dei log [59].

4.3 Architettura

Figura 16: Architettura del sistema operativo Tizen.44

L’architettura di Tizen, mostrata in Figura 16, e 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’hardwaredel dispositivo.

4.3.2 Core

Contiene l’implementazione dei servizi chiave, utilizzati sia dal Framework Web che da quelloNativo.

Al suo interno si possono identificare i seguenti sotto-componenti [54] [60]:

44Sorgente 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 lanotifica di eventi di base, come il livello di batteria basso, cambiamenti nell’orientamentodello schermo e le notifiche push.

• Base: contiene le librerie di sistema di Linux. Include il supporto per il database e per ilparsing XML.

• Connettivita: fornisce tutte le funzionalita legate alla comunicazione su rete, come 3G,Wi-Fi, Bluetooth, HTTP e NFC (Near Field Communication). Il servizio di connettivitae basato sull’utilizzo del demone ConnMan45, sviluppato da Intel.

• Grafica ed UI: gestisce lo stack dell’interfaccia grafica. Comprende EFL (EnlightenmentFoundation Libraries), un sistema di gestione delle finestre basato su X11, la gestionedegli input e OpenGL ES.

• Localizzazione: fornisce i servizi di localizzazione (LBS - Location Based Services). Ebasata su GeoClue46, un servizio che fornisce informazioni di localizzazione provenienti dadifferenti sorgenti, come GPS, WPS (Wi-Fi Positioning System), ID della cella telefonicae 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 edaudio.

• PIM (Personal Information Management): gestione dei dati dell’utente, come calendarioe lista dei contatti.

• Sicurezza: Sandboxing, controllo degli accessi, gestione dei certificati. Contiene i serviziserver di Smack, Cynara e Content Security Framework.

• System: gestisce diversi aspetti del dispositivo e di sistema: e un’interfaccia per l’ac-cesso ai sensori, al display ed alla vibrazione. Gestisce il consumo energetico. Moni-tora gli eventi sul dispositivo, come USB, MMC, alimentatore e jack audio. Si occupadell’aggiornamento del sistema. Infine, fornisce le funzionalita di sveglia e ora.

• Telefonia: fornisce le funzionalita di comunicazione con il modem del dispositivo. Im-plementa i servizi di chiamata, messaggi, trasferimenti dati a pacchetto e informazioni direte per UMTS e CDMA.

• Web: contiene l’implementazione delle Web API di Tizen, ottimizzate per il basso con-sumo 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 eaggiornamenti dei pacchetti applicativi [61]. Gestisce il ciclo di vita delle applicazioni e fornisceun’interfaccia per la gestione degli eventi di sistema. Permette lo sviluppo di applicazioni nativee di servizi in C++, fornendo l’accesso ad oltre 10000 API. Include il supporto per le libreriestandard ed open source, come glibc, libstdc++, libxml2, Open GL R© ES, Open AL R©, OpenMP R©.

45https://01.org/connman46http://freedesktop.org/wiki/Software/GeoClue/

55

4.3.4 Framework Web

Permette di eseguire le applicazioni che usano lo standard HTML5. Fornisce accesso a tuttele API definite dal consorzio W3C: video, audio, touch, 2D canvas, WebGL, CSS3, geolocaliz-zazione, vibrazione, web socket, e web worker. Inoltre le Web Device API di Tizen estendonol’accesso ai servizi di bluetooth, NFC, sveglia e messaggistica.

4.3.5 Web Runtime

Uno dei punti di forza di Tizen, e il supporto per le applicazioni Web. In tal senso, il WebRuntime e uno dei componenti di maggiore interesse nell’architettura del sistema operativo.

Il Web Runtime (WRT) e il gestore del ciclo di vita di un’applicazione web. E responsabiledella loro installazione, disinstallazione ed esecuzione [62].

Il suo ruolo, per quanto simile a quello di un browser web, differisce nell’interfaccia grafica perl’assenza dei controlli di navigazione e per l’accesso all’hardware sottostante tramite le WebAPI. 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 progettoCrosswalk [64], per lo sviluppo di una nuova versione basata su Blink, il nuovo motore di ren-dering di Google. Presentato nel 2014, e stato inserito nella versione di Tizen 3.0. Attualmentene viene rilasciata anche una versione per Android.

La creazione di un nuovo Web Runtime e stata fortemente incentivato da Intel, che desideravauno sviluppo piu aperto, senza “mailing list private”. Inoltre si voleva diminuire la differenzadi prestazioni tra le applicazioni native e Web.

Crosswalk e 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 diManifest [Il file Manifest 4.5.7], il runtime mode ed il Security Framework, l’implementazionedelle 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 richiestola definizione di un modello definito sulla base delle minacce offerte dal panorama mobilenegli ultimi anni. In Figura 17 viene riportato uno schema riassuntivo. Le principali sfide disicurezza sono state identificate [65] nella diffusione di applicazioni malevoli, creazione di Storenon autorizzati, perdita di dati sensibili, meccanismi volti ad ingannare l’utente, nell’utentestesso ed in attacchi da remoto.

A seguito e stato definito un sistema di livelli di fiducia: il kernel e trusted, ma il secure boot especifico del produttore del dispositivo. Il livello di fiducia di un’applicazione e legato a quelloassociato allo sviluppatore. L’utente, nonostante sia il possessore del dispositivo, non e fidato.Ugualmente non lo e lo sviluppatore.

Gli obiettivi di sicurezza sono stati dunque identificati nella protezione degli utenti, delleapplicazioni e del sistema [66].

47Sorgente 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 puo innalzarli. Non puo modificare il file system,ne puo mandare segnali ai servizi di sistema, ma puo comunque invocare azioni privilegiateper mezzo di applicazioni con sufficienti privilegi. In ultimo, e autorizzato ad installare le soleapplicazioni 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 connes-sioni di rete e le informazioni di run-time.

Le applicazioni possono accedere all’interfaccia grafica ed ottenere l’input dell’utente. Nonhanno privilegi di amministratore. L’accesso in scrittura e garantito solo alle proprie directory.

48Sorgente immagine: https://wiki.tizen.org/w/images/thumb/0/0a/Security Lifecycle.png/600px-Security Lifecycle.png

57

L’utilizzo delle API, sensibili per la sicurezza dell’utente, e sottoposto a restrizione. L’accessoai dati di altre applicazioni non e consentito.

Nell’elaborazione di un modello di sicurezza per Tizen, Figura 18, viene anche definito anche ilmodello del ciclo di vita sicuro delle applicazioni:

• Al termine della fase di sviluppo, l’applicazione deve essere firmata dallo sviluppatore peri controlli di autenticita ed integrita.

• Inviata allo Store, l’applicazione viene sottoposta a controllo di validazione ed in caso disuccesso, viene firmata dal distributore a conferma dell’ammissione al negozio virtuale.

• In fase di installazione e sottoposta a controllo anti-virus: il sistema operativo offreun’interfaccia per controllare che il pacchetto applicativo non sia malevole.

• Durante la fase di esecuzione, ciascuna applicazione e confinata (Sandboxing) ed e sotto-posta a controllo degli accessi.

4.4.3 Il sistema

La soluzione di sicurezza adottata deve proteggere il sistema: i servizi, le librerie condivise, idatabase, 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 e ristretto ed e garantito solo aicomponenti strettamente autorizzati. L’utente root e proprietario della maggior parte dei filedi 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 lasoluzione 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 precedentementesottoposte a processo di revisione.

• Tizen Key Manager : un deposito sicuro, protetto da una password, per chiavi, certificatie dati sensibili.

• Content Security and Reputation Framework : per la ricerca di malware e la classificazionedelle pagine Web.

• Tecniche di mitigazione delle vulnerabilita come ALSR e DEP.

58

• Protezione dell’accesso: una collezione di API per l’implementazione del blocco del di-spositivo da accessi indesiderati.

Ciascuno degli elementi precedentemente elencati verra trattato nelle successive sezioni dell’a-nalisi del sistema operativo.


Il sistema operativo Tizen impiega delle tecniche di confinamento per eseguire le applicazioni inun ambiente ristretto, in cui politiche dettagliate limitano l’accesso a risorse ed a componentidi sistema.

Tizen 2.x L’isolamento delle applicazioni viene realizzato tramite l’utilizzo congiunto diSmack, un’implementazione del modello MAC [Appendice 6.5.2], e dell’assegnazione di per-messi di accesso al file system, specifici per utenti e gruppi. Quest’ultima e una soluzione disicurezza classica in Unix ed e 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, mentrel’utilizzo degli UserID e GroupID in 4.5.3.

Tizen 3.0 La struttura utilizzata per il confinamento delle applicazioni viene modificata, neltentativo di alleggerire il ruolo di Smack all’interno del sistema operativo. Viene introdotto ilnuovo modello The three domain model ed un nuovo componente di sistema, Cynara, un policychecker per il controllo degli accessi centralizzato. Le motivazioni di tale scelta e dettagli suicomponenti 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. Aseguire, in 4.5.9 e 4.5.10 si applicano tutti i concetti analizzati in una descrizione sull’installazio-ne ed esecuzione delle applicazioni. In ultimo una descrizione di Vasum 4.5.11, un EnvironmentSeparation Mechanism.

4.5.1 Smack - Simplified Mandatory Access Control Kernel

Introduzione Smack e un Linux Security Module (LSM) [24] che implementa il modelloMandatory Access Control (MAC). E stato proposto e sviluppato da Casey Schaufler.

SELinux [27], la piu nota implementazione del modello MAC, fornisce una soluzione di sicurezzacompleta per Linux, ma appare complesso [67]. L’approccio di Smack e piu semplice ed e rivoltoa risolvere problemi di sicurezza piu piccoli, richiedendo minore configurazione ed un supportoapplicativo limitato. Smack e utile nelle implementazione di Sandboxing su Mobile per limitarel’accesso di un utente e di alcuni processi alle risorse. In ogni caso non e da considerare generalpurpose come SELinux. Smack e disponibile nel kernel Linux dalla versione 2.6.25.

Il controllo dell’accesso di Smack si fonda sull’utilizzo di etichette [68], semplici stringhe dicaratteri. Ogni soggetto, l’entita che vuole accedere ad una risorsa, ed oggetto, la risorsa,ricevono un’etichetta. Di base un soggetto puo accedere ad un oggetto solo se le due etichettesono uguali, utilizzando un confronto case sensitive. E comunque possibile definire delle regoleaccessorie per permettere diverse combinazioni.

49Sorgente 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 (comeWi-Fi, Bluetooth, 3G, GPS ed accelerometro), file, cartelle e socket.

L’idea alla base di Smack e estremamente semplice, ma il meccanismo di controllo degli accessitende a diventare complesso all’aumentare del numero di applicazioni e di risorse da controllare.Un numero molto alto di etichette e difficile da gestire, ma soprattutto puo portare ad erroried 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 e 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.

50Piu in generale tutti i processi in esecuzione.

60

Le etichette L’etichetta, label, e una stringa ASCII lunga fino a 23 caratteri. Il nomeassociato dell’etichetta e importante per aumentare la leggibilita delle regole.

Le etichette assegnate alle risorse, gli oggetti, sono confrontate con quelle del processo chetenta di accedervi, il soggetto. L’impostazione predefinita prevede che l’accesso sia consentitosoltanto se le due etichette sono uguali. Un amministratore, pero, puo aggiungere delle regolesotto forma di tupla soggetto - oggetto - diritti di accesso.

Smack non supporta le wildcard o espressioni regolari e non vale la proprieta transitiva delleregole. Ad esempio: se a puo accedere a b e b puo accedere a c, questo non vuol dire che apossa accedere a c. Affinche questo possa valere, deve essere inserita una nuova regola specifica.

Esiste inoltre un insieme di etichette Smack riservate (floor , hat ˆ, star *) alle quali si applicanoregole differenti da quelle di base. Questo permette all’amministratore di limitare il numero diregole da creare per utenti e processi.

L’implementazione Smack utilizza gli extended attributes del file system51, per salvarel’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 laconfigurazione. Le regole Smack vengono salvate nel database Smack Policy52 e caricate inmemoria kernel al boot time [69]. Per effettuare delle modifiche, basta aggiungere una nuovatupla: soggetto - oggetto - regola di accesso.

Tool Sono disponibili delle versioni modificate di alcuni tool Unix per la gestione delleetichette [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 replicarei livelli di classificazione standard dei documenti governativi: Unclass per non classificato, Cper classificato, S per segreto e TS per top secret.

Di seguito con poche regole e possibile stabilire la tradizionale gerarchia di accesso.

51Smack fa uso dell’attributo security.SMACK64 per i file e di security.SMACK64EXEC per gli eseguibili.52/sys/fs/smackfs/load

61

C Unclass rxS C rxS Unclass rxTS S rxTS C rxTS Unclass rx

Per default, Unclass sara solo in grado di accedere ai dati con la stessa etichetta, mentre perle regole definite di sopra, TS puo 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 regoleSmack permette di definire dei livelli gerarchici di accesso [72], a ciascuno dei quali e associatouno specifico caso d’uso. Nella tabella che segue, a livello crescente, corrisponde un accesso piuristretto.

Livello Utilizzo Etichetta soggetto Etichetta oggetto Accesso1 Accesso illimitato qualsiasi * rwx2 Condivisione file qualsiasi rx3 Sandboxing specifica la stessa del soggetto rwx4 Controllo accessi specifica specifica basato su regole

Il primo livello viene impiegato per fornire accesso illimitato a quelle risorse utili a tutti gliapplicativi. Questo permette un grande risparmio di regole Smack, che altrimenti sarebberodovute essere definite per ogni soggetto Smack (applicazione). Ad esempio, i direttori /dev/nulle /dev/zero ricevono l’etichetta star (*), dunque hanno accesso illimitato.

Il secondo livello viene utilizzato per la condivisione dei file tra le applicazioni. Associarealle cartelle condivise l’etichetta floor ( ), permette a qualsiasi processo l’accesso in lettura edesecuzione ai dati contenuti. Inoltre, le cartelle /lib, /bin, /usr/lib, /etc, /dev ricevono tuttel’etichetta floor (“ ”).

Il terzo livello gerarchico viene impiegato per l’implementazione del Sandboxing delle appli-cazioni: se le etichette del soggetto e dell’oggetto sono le stesse, l’accesso dell’applicazione aipropri dati viene gestito senza la necessita di definire altre, piu specifiche, regole Smack.

L’ultimo e piu restrittivo livello, il quarto, viene utilizzato per la gestione dei permessi associatialle applicazioni. In Tizen 2.x, al momento dell’installazione [4.5.9] viene creato un nuovodominio per il pacchetto applicativo e vengono definite delle regole per limitare l’accesso allesole risorse consentite.

4.5.3 UserID e GroupID

Tizen 2.x Non e un sistema operativo multi utente, ma l’utilizzo degli UserID e GroupIDe l’assegnazione dei permessi di accesso al file system rappresenta un’importante componentenel confinamento delle applicazioni [73]. Questa soluzione di sicurezza, classica di Unix, eun’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 leapplicazioni sono eseguite dall’utente app (userID 5000), nessuna dall’utente root (user ID 0).La shell di sdbd53 viene invece eseguita con user ID 5100.

53Demone 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 PermessiConfigurazione di base per tutti i file dell’utente root rw-r--r-- (644)File eseguibili e cartelle dell’utente root rwxr-xr-x (755)File del Framework estremamente importanti rw------- (600)Cartella shared nella home dell’applicazione54 User: root rwxr-xr-x (755)Cartelle data e tmp nella home dell’applicazione55 User: app rwx------ (700)File globalmente accessibili, come /dev/zero, /dev/null e /tmp 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 UserIDe 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 nelmodello di confinamento delle applicazioni, vengono qui anticipati alcuni concetti sui privilegidelle applicazioni, che verranno poi spiegati in dettaglio nella successiva sezione 4.5.7: “Ilsistema 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 effettivamenteusate per implementare la soluzione. Se da un lato questa scelta facilita la definizione deipermessi nello sviluppo delle applicazioni, dall’altro rende complicato il modo in cui i serviziastratti vengono mappati nei diversi componenti di sistema utilizzati.

Tizen 2.x La funzione di mappatura e affidata interamente a Smack, utilizzando delle po-litiche di controllo degli accessi molto dettagliate: ogni applicazione ha associato un dominioed un’etichetta. Ad ogni nuova installazione, per tutte le risorse ed i componenti a cui l’ap-plicazione ha il privilegio di avere accesso, e necessario definire delle specifiche regole Smack(ulteriori dettagli in 4.5.9). Il problema e il numero di regole: 41000 in Tizen 2.2.1 [75], cosıvasto da risultare ingestibile. Ulteriormente, non vi e distinzione tra le etichette di sistema equelle utente e viene impiegato un algoritmo di ricerca lineare, lento.

Tizen 3.0 Viene introdotto un nuovo modello di controllo degli accessi compatto, the threedomain model : tre domini, tre gruppi di etichette ed alcune regole gia definite [76].

In Tizen esistono fondamentalmente due tipi di dati:

• Dati utente di proprieta 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 e quella di dividere i dati di sistema in una parte accessibile in letturada 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 e libero, ma quello cross-dominio e ristretto e strettamente controllato.

Ad ogni dominio e 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 spiegatoin 4.5.1.

A differenza della versione precedente, dove un nuovo dominio veniva creato ad ogni installa-zione, in Tizen 3.0 i tre domini di sicurezza sono creati preventivamente. Da notare che ogniapplicazione installata, riceve ancora una propria etichetta, ma il dominio di appartenenzarimane quello User.

L’adozione del “Three Domains Model” ha permesso di rendere le regole Smack piu chiare epiu 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 nu-mero di etichette, la bassa granularita dei tre domini, non fornisce un controllo dell’accesso allerisorse sufficientemente dettagliato per garantire la protezione del sistema e di ciascuna appli-cazione. E stato quindi necessario introdurre un nuovo componente, Cynara, con la funzionedi policy checker : controllare i privilegi delle applicazioni che tentano di accedere alle risorseed alle API “privacy-sensitive”.

In Tizen, l’utilizzo congiunto di UserId e GroupID (DAC), Smack e Cynara da origine ai “I trepilastri della sicurezza di Tizen 3.0”, Firgura 20.

4.5.5 Cynara

Cynara e un policy checker e viene introdotto nella versione di Tizen 3.0 [77].

56Sorgente immagine: https://wiki.tizen.org/wiki/File:SmackCynaraDAC 443 418.png57Sorgente 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 accedeabbia privilegi sufficienti.58 In Tizen 2.x questa funzione veniva offerta da un set molto detta-gliato di regole Smack. La semplificazione introdotta dal “Three domain model” [4.5.4] rendenecessario un nuovo componente che memorizzi i privilegi associati a ciascuna applicazione edesponga una semplice chiamata API per il controllo delle policy di accesso.

Cynara fornisce un database per memorizzare i permessi associati ad un’applicazione, mantieneil complicato mapping tra i “privilegi astratti” e le risorse di sistema ed espone una libreriaclient leggera per rendere il controllo degli accessi semplice [78].

Cynara in dettaglio In riferimento alla Figura 21, il database di Cyanara viene popolatoutilizzando 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 [ulterioridettagli in 4.5.9].

• Utilizzando il Privacy Manager per gestire le scelte dell’utente nella concessione deipermessi alle applicazioni [ulteriori dettagli in 4.5.7].

Nel database, ogni applicazione univocamente identificata da un’etichetta Smack, ha associataun lista di privilegi. I servizi di sistema fanno richiesta a Cynara per il controllo dell’accessofornendo una tripletta: utente, applicazione e permesso.59 Cynara e ottimizzato per minimiz-zare i tempi di risposta, tramite cache dei risultati. Il tempo medio per un controllo di accessoe 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 inesecuzione richiede l’accesso ad un componente di sistema, ad esempio il GPS, il componente

58Vengono qui anticipati alcuni concetti sui privilegi delle applicazioni, che verranno poi spiegati in dettaglionella successiva sezione 4.5.7: “Il sistema dei privilegi”.

59Cynara e pensato per supportare un sistema operativo multi-utente.60Sorgente immagine: https://wiki.tizen.org/w/images/thumb/7/7e/CynaraSchema ver 1 0.png/750px-

CynaraSchema 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 databasedelle policy. Per un controllo piu fine, nel processo decisionale puo intervenire un un “agentesterno”, implementato nella forma di plug-in. Ad esempio, si potrebbe usare un popup, incui l’utente puo scegliere se consentire l’accesso ad una determinata risorsa. In ogni caso l’ideaalla base di Cynara e quella di offrire una risposta precisa: permesso o non permesso. Se nonviene consentito l’accesso ad una risorsa, o ad un’API privilegiata, a livello applicativo vienegenerata 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 regoleSmack, nel tentativo di isolare le singole applicazioni vengono creati dei domini separatiad ogni nuova installazione. La stessa soluzione viene adottata sia in SELinux che inAppArmor, per questo Smack viene ritenuto essere, in parte, la reinvenzione di unasoluzione esistente.

• Nella presentazione di Cynara [78], Tomasz Swierczek ha annunciato che le performancedi Cynara sono migliori rispetto ad altre soluzioni esistenti, come ad esempio Polkit.Quest’ultimo, in particolare, viene indicato come caratterizzato da scelte architetturalicarenti per l’utilizzo di Json e XML per lo storage e l’assenza di cache. Questi sembranopiu problemi implementativi, che architetturali. In ogni caso, una soluzione studiataappositamente per un sistema operativo mobile, come Cynara, puo avere alcuni vantaggi,anche in termini di velocita.

• Cynara permette anche meccanismi aggiuntivi per il controllo delle policy, tra cui popupda visualizzare all’utente. E dimostrato che demandare all’utente le decisioni di sicurezza,

61tramite l’API cynara check()

66

Figura 23: Controllo dei privilegi nel menu impostazioni.62

non e la soluzione [80]: per troppo a lungo gli utenti sono stati abituati a rispondereautomaticamente si ad ogni dialog di conferma.

Nonostante Smack presenti alcuni elementi in comune con le soluzioni esistenti, risulta esserecosı semplice, da rimanere molto interessante. Solo con il tempo si sapra se la verifica, ipermessi o le etichette di Smack possono essere falsificati da applicazioni malevoli. Con permessifalsi, un’applicazioni potrebbe accedere ai demoni di servizio ed ottenere informazioni sensibilisenza il consenso dell’utente. Inoltre potrebbe avere accesso o modificare informazioni in altreapplicazioni. 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 puocompromettere la privacy dell’utente e la stabilita del sistema.

Alcuni servizi sono sensibili per la sicurezza dell’utente e del sistema e non dovrebbero esseredisponibili per tutte le applicazioni. Per esempio, leggere un SMS e un’operazione sensibile:i messaggi in arrivo potrebbero contenere informazioni riservate e quelli in uscita potrebberocomportare una spesa per l’utente [Introduzione 1.2.1]. Quindi alcune funzionalita non devonoessere disponibili per tutte le applicazioni, ma solo per quelle per cui l’utente ha approvatodurante l’installazione, o a run time, il loro utilizzo. Le applicazioni gia 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 livellodi privilegio associato alle API e definito nel file di configurazione delle Policy di Tizen. Membridella Tizen Association, possono cambiarle in accordo con le loro necessita, nonostante siaun’operazione molto rischiosa dal punto di vista della sicurezza del sistema operativo.

62Sorgente immagine: https://developer.tizen.org/dev-guide/2.2.1/org.tizen.gettingstarted/html/tizen overview/exception handling.html

67

Le applicazioni dichiarano i permessi richiesti nel file di Manifest, ma quelli realmente concessidalla piattaforma Tizen, dipendono dalla tipologia di firma utilizzata. In fase di installazione, ilgestore dei pacchetti confronta la firma utilizzata dal distributore dell’applicazione, con quelledisponibili nel sistema per i differenti livelli di privilegio [ulteriori dettagli in 4.5.8]. Il risultatodel confronto definisce il massimo livello di privilegi disponibile per l’applicazione installata edil relativo accesso alle API.

Nella versione 2.2.1[81] di Tizen e stato aggiunto il pannello Privacy Manager nel menu Settings.Selezionando un applicazione e possibile, a posteriori, la modifica delle regole di accesso63. InFigura 23 e mostrata la schermata per l’applicazione TestApp. La modifica dei privilegi associatiad un’applicazione ha conseguenze sul funzionamento dell’eseguibile: quando un’applicazionetenta di utilizzare le API privacy-sensitive i cui privilegi di utilizzo sono stati bloccati nelleimpostazioni di privacy del dispositivo, viene generata un’eccezione64 nel codice. E importanteche in fase di sviluppo l’applicazione abbia gestito correttamente tali eccezioni. Le linee guidadi Tizen [82] consigliano di visualizzare un messaggio all’utente per spiegare il motivo per cuil’azione e stata interrotta.

Il file Manifest Il Manifest e un file in formato XML. Viene utilizzato dalle applicazioni perspecificare i privilegi per le API, i servizi utilizzati ed altri parametri come l’Id dell’applicazionee del package, l’icona e se abilitare la rotazione della schermata. Le applicazioni native edibride utilizzano un file chiamato manifest.xml, mentre quelle Web, config.xml. Di seguito vieneriportato un esempio di Manifest per le applicazioni Web [83].

<?xml v e r s i on=” 1 .0 ” encoding=”UTF−8”?><widget xmlns=” http ://www. w3 . org /ns/ widgets ” xmlns : t i z e n=” http :// t i z e n .

org /ns/ widgets ” id=” https : // github . com/01 org /webapps−annex” ve r s i o n=” 1 .0 ” width=”512” he ight=”300”>

<i con s r c=”annex−i con . png”/><content s r c=” index . html”/>

<name>annex</name><t i z e n : a p p l i c a t i o n id=”33CFo0eFJe . annex”

package=”33CFo0eFJe” r equ i r ed \ v e r s i o n=” 1 .0 ”/><t i z e n : s e t t i n g screen−o r i e n t a t i o n=” p o r t r a i t ” contextmenu=” enable ”/>

</widget>

Gerarchia dei privilegi I privilegi sono organizzati su tre livelli gerarchici [84], sulla basedei rischi di sicurezza associati al loro utilizzo.

• Public: e il livello minimo, garantito a tutte le applicazioni sviluppate con il SDK. Eaperto 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.

63La modifica dei privilegi tramite il Privacy Manager comporta, in Tizen 2.x, un aggiornamento dei da-tabase Privilege DB e Smack Policy (trattati in 4.5.9). A partire da Tizen 3.0, la modifica dei permessi diun’applicazione viene gestita dal nuovo componente Security Manager.

64SecurityError 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 primisono associati alle applicazioni native, i secondi alle applicazioni web.

Di seguito alcuni esempi di privilegi nativi:

• calendar.read : l’applicazione puo leggere gli eventi del calendario (livello public).

• appmanager.kill : l’applicazione puo chiudere altre applicazioni (livello platform).

Un esempio di privilegi web:

• packagemanager.install : l’applicazione puo installare o disinstallare pacchetti applicativi(livello platform).

Una lista esaustiva dei privilegi e disponibile nella guida per gli sviluppatori di Tizen65 66.

4.5.8 Firma delle applicazioni

In Tizen e richiesto che i pacchetti applicativi, per potere essere installati, siano firmati con lafirma dell’autore e del distributore [85].

La firma dell’autore e il meccanismo di verifica dell’appartenenza dell’applicazione allosviluppatore ed assicura l’integrita del pacchetto applicativo, cosı come e stato inviato dallosviluppatore. Permette di creare una trusted-relationship tra un’applicazione ed una sua nuovaversione, fondamentale nel processo di aggiornamento. Inoltre consente di instaurare una tru-sted inter-application-communication, un meccanismo di comunicazione tra le sole applicazionifirmate con la stessa chiave dello sviluppatore, all’interno dello stesso dispositivo. Il certificatodello sviluppatore, puo essere creato tramite il Tizen IDE.

La firma del distributore viene applicata dal distributore delle applicazioni, come il Ti-zen Store (trattato in 4.7), per certificare la provenienza e verificare l’integrita del pacchettoapplicativo, cosı come e stato pubblicato sullo Store. Fornisce la garanzia che l’applicazioneabbia superato il processo di revisione e determina il massimo livello di privilegi concessi. Adesempio, se l’applicazione viene firmata con un certificato di livello pubblico, allora avra accessoai soli privilegi di livello pubblico.

In fase di sviluppo delle applicazioni, e possibile creare una coppia di certificati temporanei perottenere il livello di privilegi partner e platform [86]. Tuttavia, a differenza dell’emulatore, pereffettuare il test su dispositivi reali e necessario che le “Opzioni per gli sviluppatori” siano stateabilitate nel dispositivo. Successivamente, in fase di distribuzione dell’applicazione, la firmatemporanea sara sostituita da quella del reale canale di distribuzione, come ad esempio il TizenStore.

La firma delle applicazioni segue le specifiche W3C67:

• L’algoritmo di firma raccomandato e RSA con SHA 256.

• La lunghezza raccomandata della chiave per RSA e di 4096 bit.

• Il metodo di digest raccomandato e SHA-256.

• Il formato di certificato raccomandato e X.509 versione 3 come specificato in [RFC5280].

65https://www.tizen.org/privilege66https://wiki.tizen.org/wiki/Security/Tizen 2.X Privileges#Privilege Categorization67http://www.w3.org/TR/widgets-digsig/

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 deldistributore sul pacchetto applicativo.

2. Viene effettuato il parsing del file di Manifest, al fine di controllare che i privilegi richiestidall’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.Poiche l’Installer viene eseguito dall’utente root, di default tutti i file sono di proprieta diroot [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 ugualeall’ApplicationID (ad eccezione della cartella shared a cui viene associata l’etichetta floor).Per default, un’applicazione e quindi in grado di accedere a tutte le sue risorse.

4. I privilegi associati dall’applicazione vengono aggiunti al database dei privilegi (PrivilegeDB).

5. I privilegi dichiarati dall’applicazione sono convertiti in regole Smack sulla base di alcunitemplate definiti in smack-privilege-config71 [88].

6. Il database delle Smack policy viene aggiornato, con l’aggiunta delle nuove regole Smackcreate al punto precedente.

68Sorgente immagine: https://wiki.tizen.org/wiki/File:Access control architecture.png69Durante la fase di installazione, tutta la gestione dei privilegi avviene tramite l’utilizzo delle libprivilege-

control API [87].70/opt/usr/apps/[APPLICATION ID]71Ciascun template ha estensione .smack e si trova in /usr/share/privilege-control.

70

Tizen 3.0 Al fine di diminuire il numero di nuove regole Smack create ad ogni nuova in-stallazione, viene introdotto un nuovo componente: Cynara [rif 4.5.4 e 4.5.5]. Il processo diinstallazione rimane simile, con la differenza dell’introduzione del Security Manager [89], undemone 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 e il demone, eseguito dall’utente root, che interviene nellacreazione di un nuovo processo [90] ed e il processo padre di tutte le applicazioni nel sistemaoperativo.

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’applicazionerichiesta.

• 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

72Sorgente immagine: https://wiki.tizen.org/wiki/File:Libprivilege-control pig1.png73L’eseguibile di un’applicazione Web e un link simbolico a /usr/bin/wrt-client.

71

label Smack associata all’applicazione. Quando l’applicazione Web viene lanciata, Tizen esegueil soft-link corrispondente, il Web Runtime inoltra la richiesta al wrt launchpad (una versionespecializzata del launchpad daemon). Le fasi seguenti sono identiche a quelle precedentementedescritte.

Tizen 3.0 Durante la fase di lancio, il Security Manager [89] setta l’etichetta Smack ed ilGroupId (DAC) del nuovo processo creato, in modo tale da garantire al processo l’accesso aipropri file. A run-time l’applicazione potrebbe richiedere l’accesso ad ad un servizio di sistemao al file system. Nel primo caso l’etichetta Smack associata al processo applicativo viene usatada Cynara per controllare se l’accesso possa essere garantito. Nel secondo, il filesystem utilizzagli 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 suimodelli del controllo degli accessi MAC e DAC. Questa soluzione permette una separazionea livello dell’applicazione, ma l’ambiente di esecuzione rimane unico. Vasum [91] e un Envi-ronment Separation Mechanism basato su Linux Containers/LXC (dettagli in Appendice 6.6),che consente di avere su uno stesso device piu ambienti di esecuzione separati, chiamati zones,ciascuno dei quali esegue virtualmente una copia del sistema operativo Tizen. Il principalebeneficio offerto e quello di avere ambienti di esecuzione separati per il test di applicazioni ma-levoli, per lo sviluppo di applicazioni che necessitano di configurazioni specifiche e per limitarele funzionalita di un dispositivo dato in dotazione. Attualmente Vasum e ancora in una fasedi sperimentazione e non e stato inserito nell’Open Build Service (OBS)75, il servizio per laraccolta dei pacchetti software di una release del sistema operativo.

Il modello logico di Vasum prevede l’esecuzione contemporanea di una versione nativa delsistema operativo, host, e di alcune istanze virtualizzate, guest.

Tizen nativo si occupa di:

74Sorgente immagine: https://wiki.tizen.org/wiki/File:VasumDiagram v1.png75https://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 ciascundispositivo, 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 operazioniprivilegiate, come l’avvicendamento della zona in foreground.

Tizen virtualizzato in una zona, e 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 leetichette Smack, siano eseguite dall’Installer [rif 4.5.9], con il quale l’applicazione di installazionespecifica di una zona comunica su socket. L’Installation Service, rispetto alla versione standarddi Tizen, necessita di alcune modifiche per supportare la gestione delle zone in Vasum.

Dal punto di vista implementativo, figura 26, Vasum e costituito da una componente Server eda una Client, di seguito analizzate.

Server Il server Vasum e un servizio systemd che implementa la maggioranza delle funziona-lita 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 inuna zona.

• Si occupa di mantenere la comunicazione sia con i client, che con i bus rispettivi di ciascunazona 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 inesecuzione e mantiene la configurazione di ciascuna. La decisione sullo scheduling dellezone, puo essere presa autonomamente, o essere richiesta esplicitamente da un servizio disistema, usando la chiamata ad un’API specifica o dall’utente, tramite il triplo click sulbottone di home.

• Sfruttando le impostazioni dello scheduler ed i Cgroup di Linux, e in grado di dare prio-rita a servizi di sistema o ad alcune applicazioni critiche in esecuzione in una zona inbackground e di congelare quelle delle altre zone.

• Fornisce un set di API per la comunicazione intra-zona, messaggi broadcast per la comu-nicazione 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’in-terno di una zona.

• Include un meccanismo di notifica per l’utente, per informarlo nel caso in cui una zona inbackground 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 Criticita progettuali ed implementative delle applicazioni

In questa sezione vengono trattate alcune tematiche che introducono delle potenziali debolezzenelle applicazioni in Tizen.

In 4.6.1, viene presentata una soluzione proprietaria per la conversione delle applicazioni daAndroid a Tizen. Se da un lato risulta essere molto attraente per l’aumento di interesse versola 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 ipotiz-zato in [92], su cui l’autore del report ha voluto indagare piu approfonditamente.

A concludere, 4.6.3, un’esposizione sul Cross Site Scripting nelle applicazioni Web. Un problemagia noto alla comunita Tizen [92], ma per cui non sono state sviluppate contromisure, ne sembrache ve ne siano in progetto.

4.6.1 Conversione automatica della applicazioni

In occasione della Tizen Developer Conference del 2013 [93], Infraware ha presentato PAGService [94], una soluzione proprietaria per la conversione automatica di applicazioni esistentiper Tizen.

Seconda l’azienda, il processo di conversione di applicazioni esistenti ha innumerevoli vantag-gi: permette di ridurre i costi di progetto, i tempi di sviluppo e di avere un time-to-marketbassissimo. Gli sviluppatori possono sviluppare a basso costo e pubblicare sul Tizen Store intempi brevi. Inoltre, per la piattaforma Tizen, avere piu applicazioni a disposizione, signifi-ca rendere il sistema operativo piu competitivo. Gli utenti non percepiscono differenze tra leapplicazioni native e convertite e possono accedere a software di alta qualita e performance,indipendentemente dalla piattaforma utilizzata.

Attualmente la maggior parte degli sviluppatori per applicazioni mobili si concentra su iOSed Android. Inoltre, quest’ultimo detiene la maggiore quota di mercato. Uno strumento diconversione automatica delle applicazioni disponibili per Android in Tizen, risulterebbe moltointeressante.

Android fornisce un ambiente di esecuzione “Hardware Indipendent”, basato sull’utilizzo di unamacchina virtuale. Il semplice porting dell’Android Runtime permette di eseguire le applicazioni

76Sorgente immagine: http://download.tizen.org/misc/media/tds2013/slides/Publishing-to-Tizen.pdf

74

Figura 27: POLARIS R© App Player nell’architettura Tizen.76

per Android in Tizen. In piu, se le i pacchetti applicativi vengono convertiti (repackaged) nelformato TPK di Tizen, e possibile anche l’upload sul Tizen Store.

Il processo richiede 3 fasi:

• Verifica: tramite POLARIS R© App Verifier, si controlla se l’applicazione e adatta allaconversione.

• Generazione: POLARIS R© App Generator (PAG) converte un’applicazione per Android,in formato APK, al formato TPK per Tizen.

• Esecuzione: POLARIS R© App Player permette di eseguire un’applicazione tramite PAGin Tizen, figura 27.

Secondo quanto riportato [95], i risultati dei test dimostrano che almeno il 50% delle applicazionipossono essere convertite usando POLARIS R© App Generator senza modifiche. Solo il 30%delle applicazioni richiede lievi modifiche. Il risultato finale dimostra come circa 80% delleapplicazioni per Android possano essere convertite ed utilizzate in Tizen.

Conclusioni dell’autore del report: Nonostante i diversi risvolti interessanti, eseguire ap-plicazioni Android in una versione personalizzata dell’Android Runtime per Tizen, ha delleimplicazioni di sicurezza. Il modello di sicurezza di Android e differente da quello di Tizen.Dalle informazioni fornite, non e deducibile come venga affrontato il problema della gestione deipermessi per le applicazioni installate. In ultimo, non e chiaro quale sia il ruolo di POLARIS R©App Player nel sistema operativo Tizen: se una semplice applicazione o un vero componentedi sistema.

4.6.2 WebGL

WebGL e una tecnologia multipiattaforma che fornisce un’API low-level per la gestione dellagrafica 3D. Nel Maggio e nel Giugno 2011, Context Information Security pubblico due report[96] [97] che evidenziarono alcune criticita 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 conseguenteperdita di dati sensibili. In seguito, Microsoft scelse di terminare il supporto di WebGL nelproprio 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 funzionalita hardware direttamente sul web.WebGL permette ad applicazioni web (tipicamente untrusted) di interagire direttamentecon i driver grafici (che operano in Kernel mode). La superficie di attacco di WebGL emolto ampia ed espone codice privilegiato e non sufficientemente robusto. Il supportobrowser per WebGL richiederebbe ai driver grafici delle garanzie di sicurezza di cui maisi era occupati fino ad ora. Se prima gli attacchi potevano risultare in un “escalationof privileges” locale, ora lo possono diventare da remoto. Inoltre e lecito aspettarsi deibug solo su alcune piattaforme con hardware video specifico, facilitando attacchi mirati.Nonostante OpenGL abbia delle funzionalita aggiuntive per permettere ai driver videouna validazione del codice 3D, queste sono da ritenersi incomplete. In Figura 28 sonomostrate le fasi di un esempio di attacco WebGL.

• La responsabilita dei software di terze parti. La dipendenza del supporto browser per We-bGL dai software di terze parti, e troppo alta per poter assicurare una navigazione websicura. I problemi di sicurezza potrebbero non manifestarsi direttamente nelle API di We-bGL, ma nei vari componenti di sistema OEM o distribuiti da vari Indipendent HardwareVendors. 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

77Sorgente immagine: http://www.contextis.com/media/images/blog-WebGL-1.width-800.png

76

sviluppatori 3D non attaccassero le vulnerabilita. Inoltre il modello di aggiornamenti uti-lizzato nei driver delle schede video, caratterizzato spesso da update annuali, non soddisfale esigenze di un robusto “processo di aggiornamenti di sicurezza”.

• Possibili scenari DoS. Tradizionalmente le minacce di un Denial of Service lato client nonsono mai state considerate severe. L’infrastruttura grafica dei sistemi operativi non e statadisegnata per difendersi da “ombre e geometrie” appositamente create da un attaccante.Un sito web malevolo potrebbe portare al blocco del sistema ed alla necessita di reboot.

4.6.3 XSS

XSS e una vulnerabilita Cross-Browser, Cross-Piattaforma e Cross-Sistema operativo che per-mette di inserire ed eseguire codice Javascript lato client. Ne sono affette le applicazioni webche elaborano dati provenienti da sorgenti non fidate e che non effettuano gli opportuni con-trolli. Un esempio e il campo di input di un form: se i dati non sono correttamente filtrati (adesempio rimuovendo il tag <script>) e sono inseriti direttamente nel DOM, e possibile iniettarecodice JavaScript da remoto, realizzando un attacco Cross Site Scripting.

Nonostante sia una vulnerabilita nota fin dai tempi dell’introduzione di JavaScript nel 1995,raggiunge la sua massima popolarita nell’Ottobre 2005 con SamyWorm [99]. Attualmentecontinua ad essere estremamente diffusa e la classifica Oswap la inserisce al terzo posto nellaTop Ten delle minacce per la applicazioni web del 2013 [100].

La crescita vertiginosa di Internet ha spinto gli sviluppatori dei browser ad aumentarne lefunzionalita per venire incontro alle nuove esigenze. Soluzioni di sicurezza e regole di buonaprassi sono state definite solo in seguito ad attacchi diffusi.

Di seguito viene presentata una lista dei principali attacchi ottenibili con la tecnica del CrossSite Scripting [92].

• Website Defacement: modifica illecita di una o piu pagine di un sito web.

• Session Hijacking: dirottamento di una sessione di lavoro autorizzata per ottenere unaccesso 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 unattaccante tutto quello che viene digitato sulla tastiera.

Le applicazioni Web, in Tizen, utilizzano le API estese di Javascript per accedere al sistemaoperativo: l’accesso al File System, la comunicazione tra le processi, l’accesso ai servizi dilocalizzazione, ai WebSocket ed a WebGL. Ogni nuova funzionalita per gli sviluppatori e ancheuna nuova funzionalita 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 popolarita a Cross Site Scripting.

Tutto nasce da un post su un blog [101]: una guida alla programmazione di una sempliceapplicazione web che visualizza gli SMS ricevuti. Inviano un normale SMS, ad esempio con iltesto “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 “Heythere!”, l’inequivocabile segno di una vulnerabilita Cross Site Scripting.

Soluzioni La soluzione migliore e che sia il Framework a trattare questi problemi, gli svilup-patori 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 vul-nerabilita di sicurezza come XSS. Ad esempio non dovrebbe essere possibile modificaredirettamente il DOM.

• Utilizzare delle librerie di JavaScript, come JQueryMobile, per il filtraggio e la codificadei dati.

• E comunque consigliato fornire delle regole di buona prassi ed insegnare agli sviluppatoridi applicazioni l’importanza di trattare correttamente i dati provenienti da fonti nonfidate.

4.7 Store

Figura 29: Screenshot che mostra alcune applicazioni scaricabili dal TizenStore.78

78Sorgente immagine: http://www.tizenexperts.com/wp-content/uploads/2015/04/Samsung-SM-Z130H-Tizen-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 ildownload di applicazioni sia gratuite che a pagamento. Lo store e accessibile tramite un’appli-cazione 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, sonosottoposte 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 quelledell’Apple App Review e promette di fornire una valutazione entro tre giorni dall’invio dell’ap-plicazione. I pacchetti applicativi sono sottoposti ad un rigoroso processo di validazione delcodice 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 correttofunzionamento, l’usabilita ed il controllo sull’adeguatezza dei contenuti esposti. La figura 30mostra le fasi della verifica: la prima, Initial Inspection & Dynamic Analysis, e principalmenteautomatizzata, la seconda, Content Review & Final Confirmation, viene eseguita da un revisorefinale.

Initial Inspection & Dynamic Analysis Inizialmente, viene effettuata un’analisi di sicu-rezza dinamica dove le applicazioni sono filtrate sulla base del rilevamento di possibili minacce:malware, utilizzo non consentito di API privilegiate, riconoscimento di pattern che identificanoun attacco. Inoltre, viene verificato che a runtime l’applicazione non possa scaricare contenutoesterno non validato.

In modo simile a Bouncer [105], il meccanismo di verifica usato da Android, il sistema di valida-zione di Tizen impiega una serie di emulatori per tracciare il comportamento dell’applicazione

79Sorgente immagine: https://developer.tizen.org/sites/default/files/documentation/tizen validation guide ver 1.4 140529.pdf

79

mentre se ne simula l’utilizzo, con l’obiettivo di scatenare ed intercettare possibili azioni malevo-li. Successivamente, il Tizen Automation System controlla le funzionalita di base ed i metadatiassociati all’applicazione, come l’adeguatezza del linguaggio utilizzato ed il supporto linguisti-co, il processo di installazione e disinstallazione, la gestione degli eventi e degli interrupt. Adesempio l’utente deve essere sempre in grado di poter effettuare una chiamata di emergenza edi rispondere ad una in arrivo.

Review & Final Confirmation In questa fase l’applicazione viene validata sulla base dellelinee guida esposte nella Tizen Validation Guide. Si effettua un controllo sull’applicazione ingenerale e su eventuali caratteristiche speciali ed infine il Content Review : una verifica suicontenuti esposti, che devono essere adeguati al limite di eta dichiarato, non devono infran-gere i diritti di copyright e devono evitare possibili problemi culturali. In ultimo, un revisoreprende la decisione finale riguardo al processo di approvazione e viene inviato un responso allosviluppatore.

Il Tizen Validation Team ha segnalato [104] quali sono attualmente le principali cause dirigetto delle applicazioni sottoposte a processo di revisione:

• Applicazioni over e sotto privilegiate: nel primo caso l’applicazione dichiara dei privilegiper funzioni che non utilizza. Nel secondo, l’applicazione non viene accettata perche nondichiara 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 rispet-tano i criteri esposti nella Tizen Validation Guide.

Per risolvere preventivamente i problemi di installazione e funzionamento, Samsung mette a di-sposizione il Remote Test Lab 80. Si tratta di un servizio gratuito per gli sviluppatori, che trami-te Web possono accedere remotamente a dispositivi fisici, per testare e configurare l’applicazioneprima della sottomissione.

4.7.2 Connessione alla Store

Non sono note informazioni circa la sicurezza della connessione al TizenStore: non e noto seesista una fase di autenticazione e se il traffico di rete sia sottoposto a cifratura. Non e statapossibile un’analisi ulteriore in quanto, attualmente, i dispositivi con Tizen installato sonovenduti nel solo mercato asiatico. Inoltre l’emulatore non dispone della TizenStore App e none possibile installarla: non e 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, gliunici paesi in cui lo smartphone Samsung Z1, il primo dispositivo con Tizen installato nati-vamente, viene commercializzato. Al momento del login, usando l’applicazione dedicata, gliutenti sono automaticamente connessi al Tizen Store del proprio paese sulla base del MobileCountry Code (MCC) della scheda SIM o di GeoIP se nessuna scheda SIM e inserita. Su In-ternet sono disponibili dei tutorial per ovviare a questa limitazione [106], basati sull’utilizzodi una connessione Virtual Private Network (VPN) per connettersi ad un server in India o inBangladesh.

80http://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,purche la firma del distributore utilizzata sia tra quelle accette dal sistema operativo. Esistonoalcuni 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 funzionalita di cifratura del file system e non si hanno notiziecirca future implementazioni. Tuttavia, e disponibile la cifratura opzionale delle risorse diun’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 encrypt ion=” enable ” />

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 avvienein fase di installazione dell’applicazione e non quando viene creato il pacchetto applicativo(wgt) in fase di sviluppo, 4.2.4. Scopo della cifratura e quello di prevenire che le applicazioniweb vengano copiate tra dispositivi [108]. L’algoritmo di cifratura e AES, la chiave vienegenerata con l’aiuto del modulo crypto del WRT, diversa per ogni file ed in seguito salvata nelSecure Storage 4.9.2 [109]. Quando l’applicazione viene eseguita, il Web Runtime decifra i fileprecedentemente 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 modellodi 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 edati 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, vieneanalizzato in Appendice 6.1.1.

81http://www.appbackr.com/tizen82http://appsfuel.com/83http://www.boostermedia.com/84http://html5-ninja.com/

81

Data la similarita dei tre componenti, e possibile che nella versione 3.0 di Tizen solo il KeyManager venga mantenuto85.

In sezione 4.9.3, viene presentato il Content Security and Reputation Framework, per la scansio-ne di dati e la classificazione di URL. In 4.9.4 una breve descrizione sulla sicurezza del moduloWiFi ed in 4.9.5 una sezione dedicata alla gestione dei certificati SSL. A concludere 4.9.6, unabreve 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, senzarivelarne 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. LeSecure Repository API espongono funzioni per immagazzinare, recuperare e rimuovere chiavi,certificati e dati. Le Secure Crypto API forniscono funzioni crittografiche: creazione di unacoppia di chiavi asimmetriche, firma digitale e verifica dei certificati.

Regole di accesso Per i dati salvati nel Key Manager e possibile definire le seguenti regoledi accesso:

• Esportabile o Non-Esportabile Solo per i dati che sono contrassegnati come esportabili, ilKey Manager restituisce il valore in chiaro del contenuto. Altrimenti, mette a disposizionedel client delle funzioni crittografiche per poter utilizzare le chiavi ed i dati, senza rivelarneil valore in chiaro.

85Informazioni provenienti da una conversazione privata con Kidong Kim ([email protected]) autoredel codice del Secure Storage.

86Sorgente immagine: https://developer.tizen.org/dev-guide/native/2.3.0/org.tizen.mobile.native.appprogramming/html/images/key manager.png

82

• Protezione con password Tutti i dati nel Key Manager sono protetti dalla password del-l’utente. Inoltre, un client puo cifrare i dati usando una password addizionale, fornita almomento dell’inserimento. Per ottenere i dati sara necessario inserire la password ognivolta.

Accesso ai dati Per default, solo il proprietario dei dati puo accedere ai propri dati. Seil proprietario fornisce l’accesso ad altre applicazioni, queste hanno il diritto di leggere e ri-muovere i dati dal database. In ogni caso, quando un’applicazione viene cancellata, i dati e leinformazioni 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 propriapassword, il LockScreen (4.10) e l’applicazione di Setting notificano il Key Manager tramitespecifiche API 88.

Quando un utente effettua il login per la prima volta, figura 33, viene generata casualmente lachiave DKEK (Domain Key Encryption Key). Se l’utente si scollega, logout, il DKEK viene ci-frato con AES 256 bit con modalita GCM e salvato in memoria secondaria. La chiave utilizzatanell’operazione di cifratura e la PKEK1, quest’ultima viene generata tramite la tecnica PBK-DF2 89, utilizzando HMAC-SHA512 con 4096 iterazioni, a partire dalla password dell’utenteunita con un Salt.

In riferimento a figura 32, al momento del login il Key Manager decifra il DKEK : viene utilizzatala password dell’utente con un procedimento identico a quello descritto precedentemente perla cifratura. Quando l’utente e loggato, la chiave DKEK si trova in chiaro in memoria. Almomento di logout il Key Manager rimuove il DKEK dell’utente dalla memoria, quindi non epiu possibile accedere ai dati cifrati. Se l’utente cambia la propria password, il Key Managercifra il DKEK con la nuova password.

87Sorgente immagine: https://wiki.tizen.org/w/images/a/a6/Key-manager-login.png88Per “login” si intente lo sblocco del dispositivo con password.89Password-Based Key Derivation Function 2 e una funzione in grado di derivare automaticamente una o

piu chiavi segrete a partire da una password, usando una funzione di hash.90Sorgente immagine: https://wiki.tizen.org/w/images/2/2a/Key-manager-keyhierarchy.png

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 delleapplicazioni:

• DDEK (Data Encryption Key for DB) e la chiave con cui viene cifrato il database di unutente.

• ADEK (Application Data Encryption Key) e una chiave che viene allocata per ciascunaapplicazione, utilizzata per cifrare i propri dati.

Con riferimento alla Figura 33, vengono di seguito forniti ulteriori dettagli sul funzionamentodel Key Manager. Le chiavi DDEK e ADEK vengono generate casualmente quando l’utenteeffettua il login per la prima volta. Durante il periodo di login dell’utente sono salvate inchiaro in memoria. Quando l’utente si scollega, vengono cifrate con AES 256 bit con modalitaGCM, per essere salvate in modo sicuro in memoria secondaria. La chiave utilizzata e PKEK2generata 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 codicesorgente 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.

91Informazioni dettagliate sul funzionamento del Key Manager sono state ottenute anche dalla lettura delcodice sorgente.

92https://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 attualmenteloggato.

4.9.2 Secure Storage

Secure storage e una tecnologia per il salvataggio sicuro dei dati utilizzato sia dai moduli dellapiattaforma Tizen, che dalle applicazioni [111].

I dati confidenziali sono salvati in forma cifrata utilizzando l’algoritmo di cifratura simmetricaAES-128 bit con modalita CBC (Cipher Block Chaining) 93 facendo uso della libreria OpenSSL.La chiave viene generata alla prima esecuzione del secure-storage server e successivamentesalvata in chiaro 94 in un file il cui path viene specificato nel campo MASTER KEY PATH nelfile di configurazione /usr/share/secure-storage/config.

In seguito alla richiesta di informazioni allo sviluppatore 95 circa questa possibile vulnerabilitadi sicurezza, e stato risposto che il file e nascosto ed i permessi sono impostati consentono alsolo utente root di accedervi. Inoltre la chiave puo essere sostituita con una hardware-fused keynel caso in cui fosse disponibile una Trustzone nel dispositivo Tizen.

Le applicazioni accedono al servizio utilizzando le secure-storage client API per salvare, leggeredati ed ottenere informazioni sui file salvati nel Secure Storage. La comunicazione con il secure-storage server viene assicurata da meccanismi di Inter Process Communication. Quest’ultimoverifica l’identita del chiamante utilizzando l’etichetta Smack del secure-storage client, se va abuon fine, esegue l’operazione richiesta.

La chiave utilizzata per cifrare le applicazioni web 4.8.1, per proteggere il codice sorgente, vienesalvata nel Secure Storage.

4.9.3 Content Security and Reputation Framework

Dalla versione 2.1, Tizen integra il Content Security and Reputation Framework (CSF), presen-tato da Samsung ed Intel in collaborazione con McAfee [112] [113]. Si tratta di un Frameworkper la scansione di dati e la classificazione di URL. Espone una collezione di API che possonoessere 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]. Ilprimo e pensato per ispezionare il contenuto di applicazioni, file e dati in memoria e puo essereutilizzato per la ricerca di Malware, Virus, Trojan e Spam. Il secondo adotta un sistema perla reputazione dei siti web, in cui gli URL vengono classificati e vengono create delle policy diaccesso per ciascuna categoria (es. gioco d’azzardo, pornografia, spyware, etc.).

La sicurezza nei sistemi operativi mobile si e da sempre focalizzata sul controllo degli accessi, neltentativo di contenere i danni di un attacco. Tuttavia il problema della diffusione del malwaresulle piattaforme mobili [Introduzione 1.2.3] rende necessario adottare soluzioni preventive,come la scansione dei file alla ricerca di signatures note, nonostante alcune limitazioni impostedalla capacita computazionale e dal consumo energetico [Introduzione 1.2.5].

93Data la carenza di materiale informativo sul Secure-storage, informazioni tecniche sono state estrapolatedalla lettura del codice sorgente.

94Testato su emulatore.95Kidong Kim ([email protected]) autore del codice del Secure Storage.96Sorgente 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 e alla base di tutti i software anti-virus, il modo in cuiquesta e stata sviluppata nella piattaforma Tizen la rende straordinariamente interessante. IlCSF e 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 ap-plicativo. Inoltre, per quanto riguarda la navigazione web, si vuole offrire un’esperienza piusicura, 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 e stato realizzato sul principio della leggerezza, di un’interfacciaAPI unificata e di essere action driven: le applicazioni possono iniziare l’operazione di scansionedi cio che desiderano, quando preferiscono. In aggiunta, essendo consapevoli dei dati chegestiscono, e possibile bilanciare l’esigenza di sicurezza e di performance.

Il CSF, essendo un Framework, non offre un’implementazione del motore di scansione, che vieneinvece fornita dal Security Engine Plug-In. La Tizen Association si limita a fornire delle lineeguida sulla sua realizzazione, ma ciascun membro puo svilupparne la reale implementazione,operando libere scelte sulla frequenza della scansione e sulla capacita computazionale richie-sta. L’utente rimane libero di scegliere un’implementazione alternativa rispetto a quella a luiproposta dall’OEM [115]. Inoltre, piu Security Engines possono coesistere nella piattaforma,anche se ciascuna applicazione puo fare accesso ad un solo alla volta, ma puo anche non essernepresente alcuno. In Figura 34 e mostrato lo schema dell’architettura del CSF.

Il Content Security Framework offre un insieme di Security API per le applicazioni utentee di sistema, un’interfaccia unificata per gli sviluppatori del Security Engine Plug-In ed unmeccanismo per la gestione dei plug-in.

In seguito vengono analizzati con maggiore dettaglio i motori di scansione che compongono ilSecurity Engine [116].

97Sorgente 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 e specifica del fornitoredel “Security Engine Plug-In”. Si ipotizza che l’operazione di scansione possa basarsi sullaricerca signatures note, oppure di pattern comportamentali noti, impiegando meccanismi euri-stici. In alternativa, per venire incontro alle limitazioni del dispositivo, si puo decentralizzarela ricerca, con connessione al cloud del fornitore della soluzione di sicurezza.

Le applicazioni client possono decidere autonomamente quando effettuare l’operazione di scan-sione, ad esempio validando il codice JavaScript prima del rendering di una pagina HTML. Idati da controllare vengono passati al Framework con l’informazione sul tipo e le loro caratteri-stiche. Poter gestire in modo personalizzato il rilevamento di una minaccia e tutto a vantaggiodell’utente, al quale viene offerta una migliore user experience.

Site Engine - URL Security Agent Fornisce un insieme API di per ottenere informazionisulla reputazione di un sito Web. Il fornitore del plug-in di sicurezza si occupa della classifica-zione e della definizione delle politiche di accesso. In seguito al rilevamento di una minaccia,come mostrato in Figura 35, l’accesso all’utente puo essere bloccato o essere rediretto ad unapagina 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 eTCSLIB HANDLE hLib ; TCSErrorCode ErrCode ; TCSScanResult ScanResult ;

hLib = TCSLibraryOpen ( ) ;i f ( hLib == INVALID TCSLIB HANDLE) {

return −1;}

// Scansione d e i d a t ii f (TCSScanData ( hLib , &ScanParam , &ScanResult ) == 0) {

. . .

87

}

// Gest ione d e i r i s u l t a t ii f ( ScanResult . iNumDetected > 0) {

// Rilevamento d i una minacciaScanResult . p fFreeResu l t (&ScanResult ) ;

}

TCSLibraryClose ( hLib ) ;

Alcuni dettagli aggiuntivi Il Security Plug-In viene installato insieme ai pacchetti applica-tivi 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 molte-plici thread. Il framework e implementato tramite librerie condivise: il Content Security Fra-mework in libsecfw.so, il Security Engine Plug-In in libengine.so. Entrambe vengono caricate arun-time nello spazio di indirizzamento del processo che invoca le Security API.

4.9.4 Wifi Security

In Tizen, Connection Manager (ConnMan) e il demone per la gestione della connettivita direte. E comunemente usato nei sistemi embedded che eseguono il kernel Linux.

L’architettura WLAN di Tizen e centrata sul sottosistema wireless di Linux IEEE-802.11 98

costituito dai componenti cfg80211 e mac80211. ConnMan utilizza wpa supplicant per interfac-ciarsi con il dispositivo Wi-Fi [117]. Per ogni rete wireless a cui ci si collega, ConnMan salva lepassword in chiaro nel file /var/lib/connman/default.profile [118], come mostrato nel seguenteesempio:

[ s e rv i ce home ]Type = w i f iName = yourSSIDSecur i ty = wpa2−pskPassphrase = yourPassPhrase

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, co-me definito dallo standard IEEE 802.11. Il modulo wpa supplicant, comune agli altri sistemioperativi 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 consi-derate 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 /op-t/etc/ssl/certs dove sono salvati tutti i certificati system trusted in formato PEM. Il nome diciascun file e il valore di hash del soggetto, che puo essere ottenuto utilizzando il comandoOpenSSL come nell’esempio seguente:

opens s l x509 −s u b j e c t h a s h o l d −noout −in c e r t i f i c a t o i n i n p u t

98http://linuxwireless.org/welcome/

88

Inoltre, in Tizen, il file ca-certificate.crt ha al suo interno salvati tutti i certificati delle Certifi-cation Authority system trusted. Di seguito ne viene riportato un estratto.

sh−3.2# cat / opt / share / cer t−svc /ca−c e r t i f i c a t e . c r t−−−−−BEGIN CERTIFICATE−−−−−MIIEEjCCAvqgAwIBAgIPAMEAizw8iBHRPvZj7N9AMA0GCSqGSIb3DQEBBAUAMHAxKzApBgNVBAsTIkNvcHlyaWdodCAoYykgMTk5NyBNaWNyb3NvZnQgQ29ycC4xHjAcBgNVBAsTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEhMB8GA1UEAxMYTWljcm9zb2Z0. . . . . .

BOSoRQTIWjM4bk0cDWK3CqKM09VUP0bNHFWmcNsSOoeTdZ+n0qA=−−−−−END CERTIFICATE−−−−−−−−−−BEGIN CERTIFICATE−−−−−MIIEIDCCAwigAwIBAgIQNE7VVyDV7exJ9C/ON9srbTANBgkqhkiG9w0BAQUFADCBqTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDHRoYXd0ZSwgSW5jLjEoMCYGA1UECxMf. . . . . .

In Tizen i certificati delle Certification Authority system trusted sono protetti da privilegi diroot. Anche se tutti gli utenti possono leggerli, sono l’utente root puo modificarli.

Nel menu impostazioni, alla voce Sicurezza [120], e disponibile un’interfaccia grafica per lavisualizzazione dei Trusted root CA certificates e per la gestione dei certificati Utente, Figura36.

Figura 36: Pagina principale del menu 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 menu per la gestione dei certificati utente permette l’inserzione e l’eliminazione di certificatinella cartella /opt/share/cert-svc/pkcs12, Figura 38. Il formato dei certificati che possono esseregestiti e limitato a PKCS12.

99Sorgente immagine: https://wiki.tizen.org/wiki/Security/Tizen 2.X cert-svc-ui100Sorgente immagine: https://wiki.tizen.org/wiki/Security/Tizen 2.X cert-svc-ui101Sorgente immagine: https://wiki.tizen.org/wiki/Security/Tizen 2.X cert-svc-ui

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 vistadella sicurezza, il principale svantaggio e la possibile introduzione di vulnerabilita di tipo Stacke Heap overflow ed underflow, format string, overflow degli indici dei vettori e variabili noninizializzate. 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 ASLRe DEP.

90

ASLR e DEP Address space layout randomization (ASLR) e Data Execution Prevention(DEP) sono tecniche di mitigazione per gli exploit che sfruttano vulnerabilita esistenti nonancora risolte [121]. ASLR e DEP non sono sostituti di un codice non sicuro, ma offronoprotezione per quelle vulnerabilita che non sono ancora state scoperte o pubblicate, riducendola probabilita 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 riferimentoin Appendice alle sezioni 6.3 e 6.4.

ASLR in Tizen Nei dispositivi mobili, l’utilizzo di ASLR, incontra alcuni ostacoli. I sistemioperativi per smartphone tentano di minimizzare il tempo di boot e di lancio delle applica-zioni, il consumo della batteria ed il footprint della memoria. Queste ottimizzazioni rendonol’implementazione tradizionale di ASLR insufficiente [122].

Nella piattaforma Tizen, non si e a conoscenza se tutti i componenti, deputati al funzionamentodi ASLR, siano implementati correttamente. Se cio non fosse, un’implementazione incompletapotrebbe lasciare aperta la strada ad attacchi che utilizzano indirizzi di ritorno che puntano adaree di memoria non randomizzate.

Nella documentazione, ASLR viene indicato come implementato a partire dalla versione diTizen 2.1. Nella sezione 4.12.2, vengono presentati i risultati di alcuni test sperimentali suASLR.

DEP in Tizen Data Execution Prevention, di default, non e completamente abilitato inTizen. I test su emulatore lo confermano. Per ulteriori dettagli sui test sperimentali, fareriferimenti alla sezione 4.12.3.

Conclusione sulle tecniche di mitigazione ASLR e DEP dovrebbero essere sempre abi-litati, anche se il loro utilizzo comporta un rallentamento del sistema. Per ottenere una difesasuperiore, andrebbero utilizzati in complemento con altre tecniche di mitigazione: estensioni delcompilatore, come StackGuard102 ed utilizzo di librerie wrapper, come Libsafe103. Tuttavia, leprime, per aver effetto, richiedono la ricompilazione di ogni file binario e le seconde potrebberonon essere compatibili con tutti i programmi.


Tizen fornisce un set di API [125] [126] per la gestione del blocco dello schermo, con o senzapassword, 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

102Nel 1997 venne introdotto StackGuard, un meccanismo volto a combattere gli attacchi buffer overflow sustack. La protezione si basa sull’utilizzo del canary, chiamato anche cookie, modificato dinamicamente e salvatoprima del valore di ritorno. Un tentativo di modifica dell’indirizzo di ritorno, modifichera anche il valore delcanary, che causera la terminazione del programma [123].

103Libsafe previene gli exploit che tentano di sfruttare le vulnerabilita di tipo format string. Libsafe e unalibreria wrapper, che include una versione piu sicura di alcune funzioni vulnerabili, come sprintf(). Se gliargomenti passati alla funzione wrapper sono ritenuti sicuri, allora viene chiama l’originale, altrimenti vieneterminato il programma preventivamente [124].

104Sorgente 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 primaviene usata solo per scongiurare un uso involontario.

In figura 39 viene mostrato lo stack delle viste quando il dispositivo e bloccato: se il LockScreene attivo, e comunque possibile visualizzare delle notifiche.

La piattaforma Tizen non fornisce alcun meccanismo per il blocco del dispositivo e la cancella-zione dei dati da remoto. E ragionevole aspettarsi soluzioni proprietarie, fornite dall’OEM deldispositivo.

4.11 Vulnerabilita note

E disponibile un sistema di “bug tracking”105 dove, per la prima volta, e comparsa l’unicavulnerabilita di Tizen nota. A quest’ultima e stato assegnato un identificativo CVE (CommonVulnerabilities and Exposures).

CVE-2012-6459 ConnMan 1.3, in Tizen, continua a far visualizzare il bluetooth come ser-vizio disponibile anche dopo che la modalita offline e stata abilitata [128]. ConnMan e undemone di sistema incaricato della gestione dei servizi di connettivita [Architettura 4.3]. At-taccanti remoti potrebbero ottenere informazioni sensibili tramite i pacchetti Bluetooth. Ilproblema e stato risolto nella versione di ConnMan 1.5. Ne e affetta la versione Tizen IVI 2.11e la vulnerabilita e stata resa nota il 1 Gennaio 2013 [129].

105https://bugs.tizen.org/

92

4.12 Analisi Sperimentale

Per l’analisi sperimentale, e stata creata una semplice applicazione Web, successivamente esegui-ta sull’emulatore. Tramite il tool Smart Development Bridge (SDB), e stato possibile ottenereuna shell sul dispositivo con utente root (altrimenti non sarebbe stato possibile eseguire nessunodei comandi di seguito citati). La versione di Tizen testata e la 2.3.

4.12.1 Test Smack label

Il comando ls -lZ, eseguito nella home dell’applicazione, permette di visualizzare il securitycontext (l’etichetta) ed altre informazioni associate alle cartelle in formato esteso.

sh−4.1# l s −lZdrwxr−xr−x 2 root root p9SmpN6Z2i 4096 Mar 22 08 :11 bindrwx−−−−−− 3 app app p9SmpN6Z2i 4096 Mar 22 08 :12 datadrwxr−xr−x 3 root root p9SmpN6Z2i 4096 Mar 22 08 :11 r e sdrwxr−xr−x 5 root root 4096 Mar 22 08 :11 shareddrwx−−−−−− 2 app app p9SmpN6Z2i 4096 Mar 22 08 :11 tmp

Dall’analisi dell’output e possibile verificare il modello di gestione dei permessi e di assegnazionedelle etichette, spiegato in sezione 4.5.

Gestione dei permessi Dalla seconda colonna dell’output del comando ls, e possibile notarela presenza dei due utenti di Tizen 2.X: l’utente root ed app. Il primo e proprietario di tutti idirettori, ad eccezione di data e tmp di proprieta dell’utente app. I permessi sono impostati inaccordo con quanto spiegato in 4.5.3. Da notare che solo l’applicazione stessa ha libero accessoin 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’eti-chetta p9SmpN6Z2i106, invece a shared, l’etichetta floor ( ). Come descritto nel paragrafo 4.5.2,associare l’etichetta p9SmpN6Z2i all’applicazione permette di implementare il Sandboxing: so-lo il processo etichettato p9SmpN6Z2i potra accedere alle risorse dell’applicazione. Viceversa,l’utilizzo dell’etichetta floor ( ) consente sempre accesso in lettura [Smack 4.5.1], permettendodi implementare una soluzione di condivisione tra le applicazioni senza necessita di definirenuove regole Smack piu specifiche ad ogni nuova installazione.

4.12.2 Test ASLR

ASLR in Tizen e abilitato a livello kernel, infatti eseguendo il comando:

cat /proc/sys/kernel/randomize va space

il risultato e 2, indicando la completa randomizzazione dello spazio di indirizzamento di unprocesso. Tuttavia, in Tizen 2.1 [130], il valore di /proc/self/personality era settato a 00040000,che corrispondeva a ADDR NO RANDOMIZE, cioe ASLR disabilitato. Il problema e statosuccessivamente risolto in Tizen 2.2 dove il valore di /proc/self/personality e stato impostatoa 00000000.

Per controllare se effettivamente ASLR fosse funzionante, si e deciso di eseguire la stessaapplicazione di test piu volte e di utilizzare il comando

106L’ApplicationID assegnato all’applicazione e 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# cat / proc /2500/maps | grep −E ’ vdso | heap | s t a c k |Web’08048000−08049000 r−xp 00000000 f e : 00 4524 / usr / bin /WebProcess08049000−0804 a000 rw−p 00001000 f e : 00 4524 / usr / bin /WebProcess0924 a000−0946e000 rw−p 00000000 00 :00 0 [ heap ]b0f9b000−b179b000 rwxp 00000000 00 :00 0 [ s tack : 2 5 0 5 ]b179c000−b1f9c000 rwxp 00000000 00 :00 0 [ s tack : 2 5 0 4 ]b2456000−b2c56000 rwxp 00000000 00 :00 0 [ s tack : 2 5 0 3 ]b7720000−b7721000 r−xp 00000000 00 :00 0 [ vdso ]bfe5d000−bfe7e000 rwxp 00000000 00 :00 0 [ s tack ]

Seconda esecuzione:

sh−4.1# cat / proc /2601/maps | grep −E ’ vdso | heap | s tack ’09319000−09519000 rw−p 00000000 00 :00 0 [ heap ]b0f95000−b1795000 rwxp 00000000 00 :00 0 [ s tack : 2 6 0 7 ]b1796000−b1f96000 rwxp 00000000 00 :00 0 [ s tack : 2 6 0 5 ]b2450000−b2c50000 rwxp 00000000 00 :00 0 [ s tack : 2 6 0 4 ]b771a000−b771b000 r−xp 00000000 00 :00 0 [ vdso ]bfc32000−bfc53000 rwxp 00000000 00 :00 0 [ s tack ]

Terza esecuzione:

sh−4.1# cat / proc /2625/maps | grep −E ’ vdso | heap | s tack ’08998000−08 b98000 rw−p 00000000 00 :00 0 [ heap ]b1023000−b1823000 rwxp 00000000 00 :00 0 [ s tack : 2 6 3 1 ]b1824000−b2024000 rwxp 00000000 00 :00 0 [ s tack : 2 6 3 0 ]b24de000−b2cde000 rwxp 00000000 00 :00 0 [ s tack : 2 6 2 9 ]b77a8000−b77a9000 r−xp 00000000 00 :00 0 [ vdso ]bfdd9000−bfd f9000 rwxp 00000000 00 :00 0 [ s tack ]

Dall’output e evidente come lo stack, lo heap e vDSO107 cambino il loro indirizzo di memoria(indicato nella prima colonna a sinistra) ad ogni esecuzione, dunque e possibile affermare cheASLR e attivo.

4.12.3 Test DEP

Lo stesso comando utilizzato nel test di ASLR, cat /proc/self/maps — grep -E ’(stack — heap)’,puo essere usato anche per verificare se DEP e abilitato.

Osservando parte dell’output del test di ASLR, in particolare i campi sui permessi (ultimacolonna a destra)

08998000−08 b98000 rw−p 00000000 00 :00 0 [ heap ]b1023000−b1823000 rwxp 00000000 00 :00 0 [ s tack : 2 6 3 1 ]

si nota come che lo stack, a differenza dell’heap, sia impostato come eseguibile (x), dunqueDEP non e abilitato.

107http://man7.org/linux/man-pages/man7/vdso.7.html

94

4.13 Conclusioni

In Tizen la sicurezza e un fattore dominante ed e stata presa seriamente in considerazionein fase di progettazione. Dall’architettura al processo di revisione delle applicazioni, in tuttosi puo riconoscere l’impegno di avere adottato le migliori soluzioni e di avere saputo trarreinsegnamenti dalle minacce esistenti nel panorama mobile degli ultimi anni.

Il software e completamente open source, in gran parte ereditato da progetti con una lungastoria alle spalle e maturi dal punto di vista della sicurezza.

Tizen e un laboratorio sperimentale in cui sono state proposte soluzioni di sicurezza comple-tamente innovative. La sua storia lo rende unico ed incredibilmente favorito sotto l’aspettoprogettuale e della sicurezza in particolare. E il risultato della fusione di diversi sistemi ope-rativi, provenienti da ambienti diversi, con differenti background e priorita distinte. Solo lemigliori tecnologie, tra quelle disponibili, sono state scelte e dove nulla era presente sono sta-te adottate nuove soluzioni. Il Content Security Framework [4.9.3] e Vasum [4.5.11] ne sonoun esempio e sono cosı interessanti da poter essere proposta la loro adozione in altri sistemioperativi Mobile.

Per certi aspetti la sicurezza in Tizen puo 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 disemplificazione ha portato le regole Smack a crescere fino al numero di 40000, rendendoleingestibili. Nella 3.0, con l’adozione del “Three domain model” le regole diminuiscono, mavengono aggiunti nuovi componenti: Cynara ed il Security Manager. In futuro per supportarenuove funzionalita, come il multi-utente [57], sara 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 laprevenzione di attacchi di tipo Cross Site Scripting [4.6.3].

Non sono date informazioni specifiche sul processo di revisione delle applicazioni pubblicatesullo Store e non e chiaro quali siano i criteri di filtraggio delle applicazioni over-privilegiate omalevoli.

Nonostante dal punto di vista teorico, grazie all’implementazione sia del modello DAC cheMAC, le soluzioni adottate siano piu sicure di quelle utilizzate da Android ed iOS, Tizen rimaneun progetto giovane, che non ha ancora raggiunto la maturita necessaria per essere definitopiu sicuro. Se la sua diffusione continuera a crescere, la comunita internazionale dedicherainevitabilmente sempre piu attenzione e possibili falle saranno scoperte e risolte.

Attualmente, il piu grosso limite di Tizen e rappresentato dagli sviluppatori delle applicazioni,che non hanno ancora maturato un vero interesse verso questa piattaforma. In tal senso e daconsiderare molto interessante la soluzione proposta per permettere un’automatica conversionedella 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 CyanogenMod Tizen

Origine Nasce con l’intento di por-tare Ubuntu anche sui di-spositivi mobile. L’ideaalla base del suo svilup-po e di ottenere un si-stema operativo congiuntomobile-desktop. Dal pun-to di vista della sicurez-za vengono utilizzate so-luzioni gia esistenti (Ap-pArmor) ed integrate connuovi strumenti in gra-do di renderne piu sem-plice l’utilizzo da partedegli sviluppatori (PolicyGroups).

E una Mod di Android,cioe una “variante” mag-giormente personalizzabilee con meno restrizioni, ingrado di accontentare unafetta di utenza sempre cre-scente. Utilizza gli stes-si meccanismi di sicurez-za di Android, ma aggiun-ge un maggiore controllosulla gestione dei permessiconcessi alle applicazioni.

E il risultato della fusio-ne di diversi sistemi ope-rativi esistenti. La sicu-rezza e un fattore domi-nante ed e stata presa se-riamente in considerazio-ne in fase di progettazio-ne. Adotta le migliori so-luzioni ed essendo il piugiovane, fa tesoro dei pro-gressi raggiunti, negli ulti-mi anni, dalla sicurezza inambito mobile.

Architettura E la stessa di Ubuntu14.04 LTS con l’aggiuntadi LXC, per la funzione dicontainer per i driver An-droid, riutilizzati per l’in-terfacciamento con l’hard-ware. Rispetto alle ver-sioni precedenti di Ubun-tu, e stato modificata so-prattutto Unity, l’interfac-cia utente, adattata an-che a schermi di forma-to diverso dagli standarddesktop.

E la stessa di Android. L’architettura e costitui-ta da quattro componen-ti chiave: il Kernel (Li-nux), il Core (implementa-zione dei servizi di base),il Framework Web ed ilFramework Nativo (a sup-porto dei rispettivi tipi diapplicazione).

Applicazionisupportate

QML (solo locale), HTML(locale o su web)

Java, LUA108, HTML Native (C++), Web(HTML, CSS e Java-script) ed Ibride (Web +Native)

Confinamentodelleapplicazioni

Basato su AppArmor (sulmodello MAC). Gli svilup-patori dichiarano all’inter-no di un file di manifesti privilegi di cui l’applica-zione ha bisogno. Sullabase di questi viene gene-rato automaticamente, almomento dell’installazio-ne, il profilo AppArmorcorrispondente.

Basato sul modello DAC.Viene riutilizzato il siste-ma tradizionale dei per-messi Unix basato sugliutenti: ogni applicazioneha un User Id diverso.

In Tizen 2.0, tramite l’u-tilizzo congiunto di Smack(modello MAC) e dell’as-segnazione di permessi diaccesso al file system, spe-cifici per utenti e gruppi(modello DAC). In Tizen3.0 si aggiunge un nuovocomponente, Cynara, unpolicy checker.

108Tramite Corona SDK [131].

96

Gestione deipermessi del-le applicazio-ni

Sfrutta i Thrusted Hel-pers: servizi per la ge-stione dell’accesso alle ri-sorse di sistema da par-te di un’applicazione. Lacomunicazione con i Th-rusted Helpers e possibilesolo se il profilo AppAr-mor lo consente. Questiservizi mostrano all’utenteun prompt di richiesta au-torizzazione, memorizzan-do la scelta, che comun-que rimane modificabile inseguito.

Secondo il modello An-droid i permessi vengonoconcessi solo al momentodell’installazione e non so-no piu modificabili. Cya-nogenMod funziona allostesso modo, ma consen-te successivamente di ri-muovere determinati per-messi. Allo stesso tempo,permette di elevare i pri-vilegi di una applicazionea quelli di amministratore,al fine di consentire le fun-zionalita aggiuntive che lodistinguono da Android.

Le applicazioni dichiaranoi permessi richiesti nel fi-le di Manifest, ma quel-li realmente concessi di-pendono dalla tipologia difirma utilizzata dal distri-butore. Tramite il pan-nello Privacy Manager nelmenu Settings, e possibi-le a posteriori la modificadelle regole di accesso.

Distribuzioneapplicazioni

Ubuntu Apps Directorye fonti aggiunte manual-mente.

Google Play Store e fontiaggiunte manualmente.

Lo store ufficiale di Tizene il TizenStore. Distribu-tori alternativi sono pos-sibili, purche la firma uti-lizzata sia riconosciuta dalsistema operativo.

Verifica del-le applicazio-ni nello Store

Processo automatico omanuale a seconda delleautorizzazioni richiestetramite i Policy Groups.

Processo in parte automa-tico ed in parte manuale

Il processo di revisione delTizenStore richiede duefasi: la prima, Initial In-spection & Dynamic Ana-lysis, e principalmente au-tomatizzata, la seconda,Content Review & Fi-nal Confirmation, vieneeseguita da un revisorefinale.

Firma delleapplicazioni

Store e, opzionalmente,sviluppatore.109

Solo sviluppatore.109 Firma dell’autore e deldistributore

Esecuzionedelle ap-plicazionicome utenteroot110

NO SI NO

Mercato del-le applicazio-ni

Molto piccolo Molto grande Medio

Tabella 2: Tabella di confronto tra i tre sistemi analizzati.

Nel corso dell’analisi e stato dimostrato come anche i sistemi operativi mobile meno diffusi (col-lettivamente quelli analizzati rappresentano meno dell’1% del mercato) facciano della sicurezzaun aspetto centrale della progettazione. I numerosi canali di attacco, di cui si e parlato nell’In-troduzione 1.2.3, rendono difficile affrontare il problema della sicurezza puntualmente per ogniminaccia e poiche il malware oggi riveste un’importanza particolare, cio che accomuna tutti e

109Non e richiesto per le app scaricate da fonti non ufficiali.110Si intende la possibilita di dare alle applicazioni privilegi di amministratore.

97

tre i sistemi analizzati, e l’isolamento delle applicazioni. Le tecniche di confinamento permetto-no di risolvere in un’unica soluzione diversi problemi di sicurezza. E interessante notare, comemostrato in Tabella 5, che i tre sistemi operativi adottino tutti soluzioni differenti, nonostantel’idea di base sia condivisa. Mentre Ubuntu Touch e CyanogenMod utilizzano soluzioni giaesistenti, in Tizen si e scelto di adottare nuovi componenti, anche se in parte basati su modellinoti.

In tutti e tre i sistemi analizzati esiste la volonta di semplificare la gestione della sicurezza, siadal lato utente che sviluppatore. Il primo caso e testimoniato dalla capacita di mostrare, inmodo facilmente comprensibile, i permessi associati ad una applicazione e di fornire interfacceintuitive per la loro gestione. Inoltre, in tutti e tre i sistemi operativi, i permessi sono statidefiniti sulla base di servizi astratti e non dei componenti di sistema che li implementano, fa-cilitandone la comprensione. Ubuntu Touch mostra i privilegi di un’applicazione sia in fase diinstallazione, che al momento del primo utilizzo. CyanogenMod li mostra solo in fase di installa-zione, ma consente di modificarli in un secondo momento. Al momento dell’installazione Tizennon richiede all’utente di accettare i privilegi di un’applicazione, ma ne permette la gestionea posteriori. A proposito, si sottolinea che mentre le applicazioni per Ubuntu Touch e Tizensono in grado di gestire il caso in cui venga revocato un permesso, quelle per CyanogenMod,essendo le stesse di Android, non possiedono normalmente questa capacita. Dunque, in Cyano-genMod revocare alcuni privilegi successivamente all’installazione rischia di minare l’instabilitadi un’applicazione. Dal punto di vista dello sviluppatore, la gestione della sicurezza e sempli-fica in quasi tutti i sistemi, anche grazie all’impiego di SDK evoluti (l’SDK di CyanogenMode lo stesso di Android). UbuntuTouch mette a disposizione semplici strumenti per specificarei permessi necessari all’applicazione in sviluppo. Al contrario, in Tizen ci sono dei margini dimiglioramento, 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 re-visione e prevalentemente automatico, solo ultimamente e stato affiancato dalla possibilitadi controllo manuale. E richiesto che le applicazioni siano firmate solo dallo sviluppatore.

• In Ubuntu Touch le applicazioni sono sempre firmate dallo store che le distribuisce e, inmodo opzionale, anche dallo sviluppatore. Anche in questo caso e prevista la possibilitadi revisione manuale delle applicazioni. Non si e in possesso di dati concreti al riguardo,tuttavia si presuppone che gli strumenti di controllo automatico delle applicazioni, utiliz-zati nello store di Ubuntu Touch, non siano avanzati come quelli di Google Play, che alcontrario vanta diversi anni di esperienza.

• Tizen presenta il modello piu sicuro: e richiesto infatti che l’applicazione sia firmata siadallo sviluppatore, che dal distributore. Il Tizen Store sottopone i pacchetti applicativiad un rigoroso processo di validazione del codice, analizzandoli con una combinazione ditecniche statiche e dinamiche. La verifica consta di due fasi, la prima e principalmenteautomatizzata, la seconda viene eseguita da un revisore finale.

Dall’analisi emerge la caratteristica distintiva di CyanogenMod: l’unico a lasciare all’utente lapossibilita di “fidarsi” di un’applicazione concedendole privilegi di amministratore. In questecondizioni, in caso di applicazione malevole, le conseguenze sarebbero devastanti. UbuntuTouch e Tizen applicano un modello di sicurezza differente, dove l’utente non e fidato, vietandoin principio la possibilita di concedere autorizzazioni potenzialmente dannose.

98

Al momento, i sistemi operativi trattati possiedono collettivamente una fetta molto piccola diun mercato dominato principalmente da Android ed iOS. Gli utenti sono sempre piu alla ricercadi semplicita ed integrazione tra i dispositivi, ragione per cui si pensa che saranno solo i sistemipiu diffusi a sopravvivere. Ubuntu Touch, dato il progetto di integrazione con Ubuntu, potradiffondersi specialmente tra gli utilizzatori della versione desktop. Tizen e un sistema operativogiovane, attualmente impiegato solo in pochi dispositivi di fascia bassa, soprattutto nel mercatoasiatico. Possiede tutti i presupposti necessari per ottenere, in futuro, una sua fascia di mercato.CyanogenMod, al contrario, e un sistema gia affermato. Tuttavia, le possibilita di crescita sonoancora grandi, essendo l’unico in grado di accontentare le esigenze di una crescente fascia diutenti 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 propriasoluzione al problema, un sistema centralizzato di gestione dei dati critici, fornito dal sistemaoperativo, e conveniente sotto diversi aspetti:

• Permette all’utente di avere una chiara visione e facile gestione dei dati critici salvati dallevarie applicazioni.

• Concentrare la funzionalita in un unico modulo facilita il processo di aggiornamento nelcaso in cui venisse scoperta una vulnerabilita.

• Consente la condivisione di un segreto tra applicazioni.

• Permette di utilizzare password piu sicure (piu lunghe e complesse) in quanto esse possonoessere memorizzate in questo modulo e protette con un’unica password da ricordare. Tut-tavia, proteggere piu segreti con un’altro segreto determina che se un attaccante scoprisseil secondo avrebbe accesso a tutti gli altri. E dunque importante scegliere una passwordmolto 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 sara prossimamente adottata in UbuntuTouch e che e attualmente inclusa in Tizen, e GNOME Keyring. Essendo una soluzione ideataper ambiente desktop, nella sua descrizione utilizzeremo il concetto di login, che in ambitomobile coincide con lo sblocco del dispositivo.

6.1.1 GNOME Keyring

GNOME Keyring e un’applicazione demone111 per la gestione di dati critici. Viene utilizzatoper la memorizzazione di segreti, password, chiavi, certificati, resi disponibili alle applicazioniche vi accedono tramite apposite API. I dati sensibili sono cifrati e memorizzati in file situatinella cartella home dell’utente112. Lo scopo di GNOME Keyring e di proteggere l’utente da:

• Furto di password dal dispositivo nel momento in cui e spento accedendo fisicamente allamemoria 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.

111Nei sistemi Unix, e piu in generale nei sistemi operativi multitasking, un demone (daemon in inglese) e unprogramma eseguito in background, che fornisce un servizio.

112I 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.

113Al momento i sistemi operativi mobili sono monoutente. Ubuntu Touch nella versione per tablet e in viadi divenire multiutente [132]. Tizen 3.0 sara un sistema multiutente.

100

Il demone puo gestire diversi portachiavi, keyring, ciascuno associato ad un file diverso situatoin /.gnome2/keyrings/ e con i propri segreti. Ogni portachiavi puo trovarsi nello stato bloccatoo sbloccato. Nel primo caso, il corrispondente file e cifrato tramite l’algoritmo AES-128 bit. Lachiave di cifratura e ricavata da quella specificata dall’utente al momento della creazione delkeyring, combinata con un sale, su cui e eseguito iterativamente (in numero compreso tra 1000e 2000) l’algoritmo di hash SHA-256.

Nel momento in cui un keyring viene sbloccato (sotto richiesta di una applicazione tramite leAPI a disposizione, oppure automaticamente al login, come descritto in seguito), viene decifratoed il risultato, in plain text, viene caricato in RAM.

Avere il contenuto di un keyring in chiaro in RAM puo essere rischioso dal punto di vista dellasicurezza. 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 accessoal 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 unacerta quantita di memoria non soggetta a swapping.

In GNOME keyring, due portachiavi hanno funzioni particolari:

• Il portachiavi di sessione. Non e associato ad alcun file in quanto non viene mai scrittosu disco: viene creato al momento del login dell’utente, salvato in memoria RAM edeliminato al logout. Le applicazioni possono utilizzarlo per salvare segreti temporanei.

• Il portachiavi di default, chiamato “login”, protetto dalla stessa password di login. Al mo-mento del login dell’utente, il modulo PAM (Pluggable Authentication Modules) comunicacon GNOME Keyring e gli fornisce la password appena inserita al fine di decifrare auto-maticamente il keyring login, che e cosı sbloccato. Il keyring viene poi automaticamenteri-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 puo 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 oo . keyr ing

[ keyr ing ]d i sp lay−name=fooctime=0mtime=0lock−on−i d l e=fa l selock−a f t e r=fa l se

[ 1 ]item−type=0di sp lay−name=key1s e c r e t=pass1mtime=1311897928ctime=0

[ 2 ]

114Ogni sistema operativo normalmente puo trasferire temporaneamente dati dalla memoria all’hard disk alfine di incrementare virtualmente la quantita di memoria disponibile.

101

item−type=0di sp lay−name=key2s e c r e t=pass2mtime=1311900380ctime=0

Possibili attacchi Sebben GNOME Keyring sia una soluzione semplice e sicura, e vulnerabilead 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 (adesempio rimuovendone la batteria) nel momento in cui uno o piu keyring sono sbloccati.La natura circuitale della maggior parte delle memorie RAM fa si che l’informazione siamantenuta per alcuni secondi/minuti anche in mancanza di alimentazione. Dunque i datisalvati in RAM sarebbero accessibili avendo diretto accesso ad essa utilizzando un secondodispositivo, oppure eseguendo il boot tramite un sistema operativo secondario. Si trattadi un attacco teoricamente fattibile, ma in pratica tecnicamente complesso.

Considerazioni sull’adozione del Keyring nei sitemi operativi mobile. GNOME key-ring e una soluzione pensata per dispositivi desktop, dove le applicazioni non sono isolate leune dalle altre: consente ad ogni applicazione eseguita dall’utente autenticato di accedere alleinformazioni contenute nei keyring sbloccati. In ambito mobile e necessario introdurre unaseparazione tra le applicazioni, in modo che ciascuna sia in grado di specificare le regole diaccesso 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, relativisoprattutto alla protezione a livello software: isolamento delle applicazioni, gestione privilegi,firma della applicazioni. Trattandosi di dispositivi mobili, una componente di sicurezza im-portante e rappresentata delle comunicazioni con l’esterno, principalmente tramite WiFi e retecellulare GSM. Per ovvie ragioni di interoperabilita tra diversi dispositivi, le soluzioni qui adot-tate sono regolamentate da standard internazionali. Tuttavia, vista l’importanza che rivestononel campo della sicurezza mobile, riteniamo opportuno fornire una breve descrizione di alcunidei meccanismi di sicurezza adottati.

6.2.1 GSM

Nelle comunicazioni via GSM si distinguono due parti principali: la stazione mobile (lo smart-phone o tablet, contenente una scheda SIM) e l’operatore GSM (che comunica tramite le sta-zioni base). La sicurezza del GSM prevede l’autenticazione della stazione mobile e la cifraturadei dati trasmessi. L’operatore non e autenticato, tuttavia, come viene in seguito spiegato, eimpossibile 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 diautenticazione e cifratura utilizzato nel GSM 115. Si suppone che l’operatore abbia gia ricevuto

115Viene tralasciata la descrizione degli algoritmi A3, A5, A8 utilizzati.

102

dalla stazione mobile comunicazione dell’IMSI ( International Mobile Subscriber Identity) dellaSIM, 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 stazionemobile.

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, RAND). L’operatore conosce Ki

dai propri registri, tenuti segreti, mentre la stazione mobile contiene tale dato all’internodella SIM.

3. La stazione mobile invia SRES all’operatore, che lo confronta con quello da lui calcolatoper verificarne l’uguaglianza.

4. Stazione mobile e operatore calcolano la chiave di cifratura di 64 bit come Kc = A8(RAND,Ki).

5. Le future comunicazioni sono cifrate con l’algoritmo A5 (stream cipher, implementatoefficientemente in hardware) e la chiave Kc.

Come visibile in Figura 40, gli algoritmi A3 e A8 sono implementati direttamente in hardwaresulla SIM. Cio e fondamentale ai fini della sicurezza, in quanto consente di non rendere maileggibile alla stazione mobile la chiave Ki [134][135].

6.2.2 WiFi

La protezione della connessione WiFi e implementata usando 3 diversi protocolli: WEP, WPA,WPA2. Il primo attacco per WEP (Wired Equivalent Privacy) e stato scoperto nel 2001 [136].In seguito altri attacchi sono stati formulati, sfruttando diverse tecniche nel 2004, 2005, 2007 e2010 [137]. Piu recentemente, anche su WPA sono state scoperte vulnerabilita nel 2008 [138],2009 e 2010 [137]. Attualmente WPA2 e il protocollo piu sicuro ed utilizzato.

WPA2 prevede sia l’autenticazione che la cifratura. L’autenticazione puo avvenire in due modi:

116http://pages.cpsc.ucalgary.ca/

103

• WPA Personal : detto anche WPA-PSK (Pre Shared Key), e progettato per abitazioni epiccole reti. Non necessita di un server di autenticazione. Viene impostata una passwordnell’Access Point (ad esempio il router WiFi) e la stessa va digitata sul dispositivo mobileal momento della connessione.

• WAP Enterprise: dello anche WPA-802.1X, e progettato per reti aziendali e necessita diun server di autenticazione RADIUS. Il setup e piu complicato, ma fornisce maggiore sicu-rezza (ad esempio protezione contro attacchi dizionario). Utilizzando l’Extensible Authen-tication Protocol (EAP), consente di utilizzare per l’autenticazione token cards (SmartCards), Kerberos, one-time passwords, certificati e autenticazione con chiave pubblica.

L’autenticazione si articola in due fasi:

Prima fase: L’utilizzo della modalita WPA Personal o WPA Enterprise determina il modoin cui viene eseguita la prima fase della procedura di autenticazione, in cui stazione mobile epunto di accesso devono arrivare a conoscere una stessa Pairwise Mater Key (PMK) di 256 bit.

In WPA Personal, la PMK e calcolata da entrambe le parti applicando la funzione PBKDF2alla password della connessione: l’SSID e utilizzato come sale e sono eseguite 4096 iterazioni diHMAC-SHA1.

In WPA Enterprise, la PMK e gia nota alla stazione mobile (in modi diversi a seconda delmetodo di autenticazione utilizzato) e viene resa nota al punto di accesso in seguito all’auten-ticazione eseguita col server RADIUS. A differenza del caso WPA Personal, la PMK e diversaper ogni utente con accesso alla rete.

Al termine della procedura sotto illustrata, nel caso WPA Enterprise si avra autenticazionedello specifico utente con accesso alla rete, mentre in WPA Personal si ha autenticazione di ungenerico utente a conoscenza della password della rete.

Seconda fase: La seconda fase della procedura di autenticazione prevede che stazione mobilee punto di accesso provino l’uno all’altra di essere a conoscenza della PMK. Cio avviene conun meccanismo di four-way handshake descritto nel protocollo IEEE 802.11i [139]. Poichela PMK e 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 datitra stazione mobile e punto di accesso. Tali chiavi, di 128 bit, sono generate sempre nel corsodel four-way handshake e la procedura e ripetuta periodicamente allo scadere di un timeout.

Le PTK sono utilizzate per cifrare la comunicazione tra stazione mobile e punto di accesso, cheavviene secondo il protocollo CCMP basato su AES in modalita CCM (che combina CTR perla confidenzialita e CBC-MAC per autenticazione e integrita).

WPA supplicant wpa supplicant implementa e gestisce l’autenticazione, l’associazione e lanegoziazione delle chiavi del driver WLAN con un Autenticatore WPA, o l’autenticazione EAPcon un server di autenticazione. wpa supplicant e un demone di sistema che viene eseguito inbackground ed e il componente designato per il controllo della connessione wireless [140].

Di seguito i principali passaggi utilizzati per associare un dispositivo wifi ad un Access Pointusando WPA2 [141]:

1. wpa supplicant richiede al driver del kernel di eseguire una scansione per individuare levicine 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 diautenticazione 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 modalita WPA Personal e necessario compilareil file configurazione /etc/wpa supplicant.conf con le informazioni sulla rete, come nell’esempiosotto riportato. Nel caso in cui siano a disposizione dei tool grafici, la compilazione del fileavviene in modo automatico. E interessante notare come il valore della password, psk, vengasalvato in chiaro.

network={s s i d=”home”s c a n s s i d=1key mgmt=WPA−PSKpsk=” very s e c r e t passphrase ”}

Se nel campo PSK la password viene scritta in caratteri ASCII tra apici, al momento della con-nessione 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. Alter-nativamente, per evitare di memorizzare la password PSK ASCII in chiaro [142], e possibileutilizzare il programma wpa passphrase per generare la chiave PMK e memorizzare diretta-mente quest’ultima. E importante rimarcare come questa non sia una misura di sicurezza perla protezione della password della rete wifi: il valore della chiave PMK calcolato viene sempresalvato in chiaro. Copiando questo valore nel file di configurazione /etc/wpa supplicant.conf esufficiente per connettersi alla rete wifi. Resta comunque una misura di sicurezza interessantenel 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 e una tecnica di sicurezza che impiega il posizionamento casuale di aree di memoriachiave all’interno dello spazio di indirizzamento di un processo. Introducendo un ordinamentocasuale nel layout di memoria di un programma, ASLR ne diminuisce la predicibilita e riducela possibilita che un tentativo di exploit abbia successo [121].

Nelle comuni tecniche di exploit, per eseguire codice malevole, viene sovrascritto l’indirizzodi ritorno di una funzione utilizzando dei puntatori hard-coded. L’utilizzo di ASLR riduce lapredicibilita degli indirizzi di memoria, perche lo spazio di indirizzamento viene randomizzatoad ogni esecuzione del programma. La probabilita che un tentativo di exploit mandi in crashil processo e alta. Sebbene un attacco di questo tipo potrebbe essere ancora utilizzato per undenial 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 e disponibile dalla versione2.6.12 del Kernel Linux, pubblicata nel giugno 2005.

ASLR non e una soluzione perfetta[143]: la sicurezza offerta e basata su diversi fattori cheincludono il grado di predicibilita del layout di memoria di un programma, quando e tolleranteuna tecnica di exploit al layout di memoria ed il numero di tentativi un attaccante e in grado dieseguire. La sua efficacia dipende anche dal numero di bit dell’indirizzo di memoria utilizzatinella randomizzazione: ogni bit in piu duplica il numero dei possibili layout di memoria. L’u-tilizzo di un’architettura a 64 bit e notevolmente piu efficace: la maggior parte degli attacchibrute-force su un’architettura a 32 bit non avranno successo in una a 64 bit. Uno degli svan-taggi dell’utilizzo di ASLR e quello di rendere l’operazione di analisi dei crash e di debug piucomplicata. Per questo motivo e quasi sempre possibile disattivarlo.

6.4 Data Execution Prevention

DEP e una tecnica di mitigazione degli exploit che rende l’area di memoria in cui vengonosalvati i dati non eseguibile, prevenendo l’esecuzione di codice arbitrario [144]. L’architetturadei calcolatori moderni permette a codice e dati di coesistere nella stessa regione di memoriacontemporaneamente: i programmi possono essere piu facilmente caricati da disco e gli aggior-namenti software sono piu semplici [123]. Per implementare DEP, i dispositivi moderni usanouna combinazione di tecniche hardware e software. Entrambi i processori ARM e x86 prevedo-no la non esecuzione delle aree di memoria riservate ai dati, ma ciascuna piattaforma utilizzatecnologie leggermente diverse, che devono essere supportate a livello Kernel. Se un program-ma tenta di eseguire un’area di memoria marcata come non eseguibile, a livello di processoreviene generato un segnale di fault. In seguito, viene gestito dal kernel del sistema operativo econseguentemente 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 nonautorizzati e garantiscono l’integrita delle politiche di sicurezza che stabiliscono le regole diaccesso e condivisione delle informazioni all’interno di un sistema [145].

I modelli di seguito brevemente trattati sono il “Discretionary access control” ed il “MandatoryAccess Control”,

106

6.5.1 Discretionary access control

DAC e un modello di controllo degli accessi che permette all’utente di decidere, in mododiscrezionario (“Discretionary”), i diritti di accesso agli oggetti di sua proprieta [145].

Storicamente, i sistemi operativi derivati da Unix usano il modello DAC [146]. L’implementa-zione si basa sul concetto di proprieta e permessi di accesso (lettura, scrittura, esecuzione). Adogni oggetto di sistema, come file e cartelle, viene associato un utente ed un gruppo proprietaried i permessi di accesso per l’utente ed il gruppo proprietari e per tutti gli altri.

La flessibilita del modello, ma anche la sua principale debolezza, e data dalla possibilita pergli utenti di cambiare i permessi dei propri file. Ad esempio, un utente potrebbe dare accessoin lettura, scrittura ed esecuzione a chiunque alla propria directory home. In seguito, nullapotrebbe prevenire che altri utenti o processi accedano al contenuto della cartella in questione.

Le scelte sul controllo degli accessi vengono prese dall’utente individuale, indipendentementedalla presenza di una politica globale, introducendo possibili inconsistenze [145]. Inoltre, il mo-dello e fortemente insicuro in presenza di programmi malevoli: un malware potrebbe cambiarele politiche DAC di accesso ad alcuni file, per conto dell’utente che lo esegue.

6.5.2 Mandatory Access Control

MAC e un modello di controllo degli accessi in cui una politica di sistema decreta (“Mandatory”)“a chi e consentito avere accesso a ciascun oggetto”. Gli utenti individuali non possono alterarele scelte.

In un sistema operativo che implementa il modello “Mandatory Access Control” la politica diaccesso e stabilita da un amministratore [146]. Anche se venissero cambiate le impostazioniDAC nella cartella “home” di un utente, se esiste una politica che previene che altri utenti oprocessi vi accedano, prevale quest’ultima. Le politiche MAC possono essere definite in modomolto dettagliato, per controllare ad esempio l’accesso tra utenti, file, direttori, memoria, socketudp e tcp, ecc.

6.6 LXC / Linux Containers

LXC e una soluzione di virtualizzazione leggera, nota anche come “virtualizzazione a livellodi sistema operativo” [147]. L’unita virtualizzata e il container, che fornisce l’isolamento delprocesso e delle risorse: permette di eseguire in modo sicuro piu applicazioni su un singolosistema senza il rischio che queste interferiscano tra loro. Se la sicurezza di un container venissecompromessa, gli altri container rimarrebbero non affetti.

LXC e leggero e “resource-friendly” [148]: consente di eseguire istanze multiple di un sistemaoperativo e delle relative applicazioni su un singolo host, senza avere overhead in termini diCPU e memoria. Risulta essere piu veloce rispetto all’alternativa virtualizzazione completa,avendo un footprint medio fino a dieci volte inferiore [149].

Un container e 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’isolamentodelle risorse, i secondi per la loro limitazione ed accounting. Ad esempio, i container possonoessere configurati per usare una differente quantita di risorse in termini di CPU, memoria eI/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 e 8 a 1. http://www.ilsole24ore.com/art/tecnologie/2013-05-31/smartphone-sono-miliardi-saranno-185531.shtml.

[3] Infonetics Research. Infonetics projects mobile device security software market to reach3.4 billion in 2018. http://www.infonetics.com/pr/2014/2H13-Mobile-Security-

Client-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 onSecurity 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 Pro-ceedings of the 18th ACM conference on Computer and communications security, pages551–562. ACM, 2011.

[6] A cryptolocker for android? https://blog.kaspersky.com/new-ransomware-for-

android/.

[7] Mariantonietta La Polla, Fabio Martinelli, and Daniele Sgandurra. A survey on securityfor mobile devices. Communications Surveys & Tutorials, IEEE, 15(1):446–471, 2013.

[8] Siemens s55 sms send prompt bypass weakness. http://marc.info/?l=secunia-sec-

adv&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. http:

//www.symantec.com/connect/blogs/simplocker-first-confirmed-file-

encrypting-ransomware-android.

[14] A detailed analysis of the first locking and file encrypting ransomware for android.https://hackmag.com/malware/a-detailed-analysis-of-the-first-locking-

and-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-i-

file_12149.

108

http://www.agoravox.it/I-dispositivi-mobili-connessi.html

http://www.agoravox.it/I-dispositivi-mobili-connessi.html

http://www.ilsole24ore.com/art/tecnologie/2013-05-31/smartphone-sono-miliardi-saranno-185531.shtml

http://www.ilsole24ore.com/art/tecnologie/2013-05-31/smartphone-sono-miliardi-saranno-185531.shtml

http://www.infonetics.com/pr/2014/2H13-Mobile-Security-Client-Software-Market-Highlights.asp

http://www.infonetics.com/pr/2014/2H13-Mobile-Security-Client-Software-Market-Highlights.asp

https://blog.kaspersky.com/new-ransomware-for-android/

https://blog.kaspersky.com/new-ransomware-for-android/

http://marc.info/?l=secunia-sec-adv&m=108315642409515

http://marc.info/?l=secunia-sec-adv&m=108315642409515

http://www.fortiguard.com/files/Intrusion_and_Protection_of_Mobile_Devices.pdf

http://www.fortiguard.com/files/Intrusion_and_Protection_of_Mobile_Devices.pdf

https://www.f-secure.com/v-descs/cabir.shtml

http://www.symantec.com/connect/blogs/fakeav-holds-android-phones-ransom

http://www.symantec.com/connect/blogs/fakeav-holds-android-phones-ransom

http://www.symantec.com/connect/blogs/simplocker-first-confirmed-file-encrypting-ransomware-android



https://hackmag.com/malware/a-detailed-analysis-of-the-first-locking-and-file-encrypting-ransomware-for-android/

https://hackmag.com/malware/a-detailed-analysis-of-the-first-locking-and-file-encrypting-ransomware-for-android/

http://www.bromium.com/sites/default/files/bromium-report-ransomware.pdf

http://www.bromium.com/sites/default/files/bromium-report-ransomware.pdf

http://www.ilsoftware.it/articoli.asp?tag=Cryptolocker-e-altri-ransomware-come-decodificare-i-file_12149



[17] Faq ubuntu touch. https://wiki.ubuntu.com/Touch/FAQ.

[18] Ricardo Salveti. Ubuntu touch internals. https://www.youtube.com/watch?v=

O2qEAbuk_i8.

[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

https://wiki.ubuntu.com/Touch/FAQ

https://www.youtube.com/watch?v=O2qEAbuk_i8

https://www.youtube.com/watch?v=O2qEAbuk_i8

https://wiki.ubuntu.com/Touch/ContainerArchitecture

https://wiki.ubuntu.com/UnityNextSpec

http://en.wikipedia.org/wiki/QML

http://en.wikipedia.org/wiki/Qt_%28software%29

https://en.wikipedia.org/wiki/Linux_Security_Modules

https://www.youtube.com/watch?v=mp23AO8qtE4

https://www.youtube.com/watch?v=mp23AO8qtE4

http://manpages.ubuntu.com/manpages/gutsy/man7/capabilities.7.html

http://manpages.ubuntu.com/manpages/gutsy/man7/capabilities.7.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/

http://mdeslaur.blogspot.ch/2013/12/ubuntu-touch-and-user-privacy.html

http://mdeslaur.blogspot.ch/2013/12/ubuntu-touch-and-user-privacy.html

https://design.ubuntu.com/apps/patterns/content-hub

https://developer.ubuntu.com/en/apps/platform/guides/content-hub-guide/

https://developer.ubuntu.com/en/apps/platform/guides/content-hub-guide/

https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning

https://wiki.ubuntu.com/SecurityTeam/Specifications/ClickPackageSigning

https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement

https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement

http://www.linuxjournal.com/article/9400

http://www.linuxjournal.com/article/9400

https://wiki.archlinux.org/index.php/Disk_encryption

https://wiki.archlinux.org/index.php/ECryptfs

http://stackoverflow.com/questions/5835664/how-does-apparmor-do-environment-scrubbing

http://stackoverflow.com/questions/5835664/how-does-apparmor-do-environment-scrubbing

https://preyproject.com/

http://en.wikipedia.org/wiki/CyanogenMod

http://wiki.cyanogenmod.org/w/About

http://www.cyanogenmod.org/about

[41] Rooting (android os). http://en.wikipedia.org/wiki/Rooting_%28Android_OS%29.

[42] Android Wiki. Content providers. https://source.android.com/devices/tech/

security/index.html.

[43] Cyanogenmod privacy guard updated and merged with cm10.2. http:

//androidcommunity.com/cyanogenmod-privacy-guard-updated-and-merged-

with-cm10-2-20130925/.

[44] Ryan Whitwam. App ops was never meant for end users, used for internal testing and de-bugging only. http://www.androidpolice.com/2013/12/11/googler-app-ops-was-

never-meant-for-end-users-used-for-internal-testing-and-debugging-only/.

[45] Protecting your privacy: App ops, privacy guard, and xprivacy. http://www.xda-

developers.com/protecting-your-privacy-app-ops-privacy-guard-and-

xprivacy/.

[46] Jonathan Feist. Superuser settings to be handled in cyanogenmod 12 through privacyguard. http://androidcommunity.com/cyanogenmod-privacy-guard-updated-and-

merged-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-ground-

on-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-creating-

hybridnative-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

http://en.wikipedia.org/wiki/Rooting_%28Android_OS%29

https://source.android.com/devices/tech/security/index.html

https://source.android.com/devices/tech/security/index.html

http://androidcommunity.com/cyanogenmod-privacy-guard-updated-and-merged-with-cm10-2-20130925/



http://www.androidpolice.com/2013/12/11/googler-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-was-never-meant-for-end-users-used-for-internal-testing-and-debugging-only/

http://www.xda-developers.com/protecting-your-privacy-app-ops-privacy-guard-and-xprivacy/





http://www.cyanogenmod.org/blog/cyanogenmod-account

http://www.scottbrownconsulting.com/2013/08/cyanogenmod-breaks-new-ground-on-mobile-privacy/



https://it.wikipedia.org/wiki/Dispositivo_a_blocchi

https://en.wikipedia.org/wiki/Dm-crypt

https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_.28ESSIV.29

https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_.28ESSIV.29

https://source.android.com/devices/tech/security/encryption/

https://events.linuxfoundation.org/images/stories/pdf/lceu2012_haitzler.pdf

https://events.linuxfoundation.org/images/stories/pdf/lceu2012_haitzler.pdf

http://www.slideshare.net/SymphonyTeleca/practical-approach-to-creating-hybridnative-tizen-apps

http://www.slideshare.net/SymphonyTeleca/practical-approach-to-creating-hybridnative-tizen-apps

https://wiki.tizen.org/wiki/Multi-user_Architecture

https://developer.tizen.org/documentation/articles/smart-development-bridge

https://developer.tizen.org/documentation/articles/smart-development-bridge

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Debugging_Environment

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Debugging_Environment

[60] Tizen architecture overview. https://www.tizen.org/sites/default/files/tizen-

architecture-linuxcollab.pdf.

[61] Byung Woan Kim. Overview of the tizen native application framework.http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-

Overview_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. https://wiki.tizen.org/wiki/Security/Tizen_3.X_

Overview.

[66] Security/tizen 2.x overview. https://wiki.tizen.org/wiki/Security/Tizen_2.X_

Overview.

[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. https://wiki.tizen.org/wiki/Security/

Tizen_2.X_libprivilege-control.

[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. https://wiki.tizen.org/wiki/Security/Tizen_2.X_

Smack.

[73] Security/tizen 2.x user id & group id. https://wiki.tizen.org/wiki/Security/

Tizen_2.X_User_ID_%26_group_ID.

[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. https://wiki.tizen.org/wiki/Security:

SmackThreeDomainModel.

[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

https://www.tizen.org/sites/default/files/tizen-architecture-linuxcollab.pdf

https://www.tizen.org/sites/default/files/tizen-architecture-linuxcollab.pdf

http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-Overview_of_the_Tizen_Native_Application_Framework.pdf

http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-Overview_of_the_Tizen_Native_Application_Framework.pdf

https://developer.tizen.org/dev-guide/2.2.0/org.tizen.web.appprogramming/html/basics_tizen_programming/web_runtime.htm

https://developer.tizen.org/dev-guide/2.2.0/org.tizen.web.appprogramming/html/basics_tizen_programming/web_runtime.htm

https://download.tizen.org/misc/media/conference2012/tuesday/ballroom-a/2012-05-08_1515-1555-tizen_web_runtime.pdf



http://lwn.net/Articles/618152/


https://wiki.tizen.org/wiki/Security/Tizen_3.X_Overview





http://linuxplumbersconf.org/2009/slides/Casey-SmackPlumbers2010.pdf

http://linuxplumbersconf.org/2009/slides/Casey-SmackPlumbers2010.pdf

https://wiki.tizen.org/wiki/Security/Tizen_2.X_libprivilege-control


http://www.schaufler-ca.com

https://wiki.tizen.org/wiki/Security:Smack

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Smack

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Smack

https://wiki.tizen.org/wiki/Security/Tizen_2.X_User_ID_%26_group_ID

https://wiki.tizen.org/wiki/Security/Tizen_2.X_User_ID_%26_group_ID

https://wiki.tizen.org/wiki/Multi-user_Architecture

https://lwn.net/Articles/552787/

https://wiki.tizen.org/wiki/Security:SmackThreeDomainModel

https://wiki.tizen.org/wiki/Security:SmackThreeDomainModel

https://wiki.tizen.org/wiki/Security:Cynara



https://wiki.tizen.org/wiki/Security:Cynara:ComparisonWithOtherSolutions

https://wiki.tizen.org/wiki/Security:Cynara:ComparisonWithOtherSolutions

[80] Franziska Roesner, Tadayoshi Kohno, Alexander Moshchuk, Bryan Parno, Helen J Wang,and Crispin Cowan. User-driven access control: Rethinking permission granting in mo-dern operating systems. In Security and privacy (SP), 2012 IEEE Symposium on, pages224–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/dev-

guide/2.2.1/org.tizen.gettingstarted/html/tizen_overview/exception_

handling.htm.

[83] Security/webapps and smack. https://wiki.tizen.org/wiki/Security/WebApps_

and_Smack.

[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. https://wiki.tizen.org/wiki/Security/

Tizen_2.X_libprivilege-control.

[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-1640-

breaking_same-origin_for_fun_and_profit.pdf.

[93] Ltd. Hyeokgon Ryu, Infraware Technology. Publishing to tizen using the automatedconversion/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-to-

tizen-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

https://developer.tizen.org/tizen-sdk

https://developer.tizen.org/dev-guide/2.2.1/org.tizen.gettingstarted/html/tizen_overview/exception_handling.htm



https://wiki.tizen.org/wiki/Security/WebApps_and_Smack

https://wiki.tizen.org/wiki/Security/WebApps_and_Smack

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Privileges

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Privileges

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Architecture

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Architecture



https://wiki.tizen.org/wiki/Security/Tizen_2.X_smack-privilege-config

https://wiki.tizen.org/wiki/Security/Tizen_2.X_smack-privilege-config

https://wiki.tizen.org/wiki/Security/Tizen_3.X_Security_Manager

https://wiki.tizen.org/wiki/Security/Tizen_3.X_Security_Manager

http://comments.gmane.org/gmane.comp.handhelds.tizen.devel/17

http://comments.gmane.org/gmane.comp.handhelds.tizen.devel/17

https://wiki.tizen.org/wiki/Security:Vasum

https://download.tizen.org/misc/media/conference2012/tuesday/seacliff/2012-05-08-1600-1640-breaking_same-origin_for_fun_and_profit.pdf



http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-Publishing_to_TIZEN_Using_the_Automated_Conversion-Repackaging_of_Existing_Android_Apps.pdf



http://pag.polarismobile.com/login

http://www.whatistizen.com/conversion-of-existing-android-apps-to-tizen-apps-using-polaris-app-generator-pag/

http://www.whatistizen.com/conversion-of-existing-android-apps-to-tizen-apps-using-polaris-app-generator-pag/

[97] James Forshaw, Paul Stone, and Michael Jordon. Webgl-more webgl security flaws. Con-text 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-tizen-

application-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 windo-ws. http://www.downloadtizenapps.com/2015/02/tutorial-how-to-access-the-

tizen-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/web-

application-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/native-

application/security/key-manager.

[111] Tizen 2.x secure-storage. https://wiki.tizen.org/wiki/Security/Tizen_2.X_

Secure-storage.

[112] Inc. Sreenu Pillutla, Director of Engg. McAfee. Content security framework.http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-

Content_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. https://lwn.net/

Articles/553676/.

[115] Tizen’s content security framework. https://developer.tizen.org/forums/general-support/tizens-content-security-framework.

113

http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx

http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx

http://namb.la/popular/tech.html

https://giscaro.wordpress.com/2012/04/10/a-simple-sms-reader/

https://giscaro.wordpress.com/2012/04/10/a-simple-sms-reader/

http://it.wikipedia.org/wiki/Tizen

https://developer.tizen.org/sites/default/files/documentation/tizen_validation_guide_ver_1.4_140529.pdf

https://developer.tizen.org/sites/default/files/documentation/tizen_validation_guide_ver_1.4_140529.pdf

http://download.tizen.org/misc/media/conference2014/slides/tdc2014-tizen-application-validation.pdf



http://www.downloadtizenapps.com/2015/02/tutorial-how-to-access-the-tizen-store-in-samsung-z1-using-vpn-laptop-in-windows.html

http://www.downloadtizenapps.com/2015/02/tutorial-how-to-access-the-tizen-store-in-samsung-z1-using-vpn-laptop-in-windows.html

http://permalink.gmane.org/gmane.comp.handhelds.tizen.devel/5056

http://permalink.gmane.org/gmane.comp.handhelds.tizen.devel/5056

https://developer.tizen.org/fr/forums/web-application-development/wgt-package-source-code-encryption?langswitch=fr

https://developer.tizen.org/fr/forums/web-application-development/wgt-package-source-code-encryption?langswitch=fr

https://tizendevelopers.wordpress.com/2013/09/30/web-application-protection/

https://tizendevelopers.wordpress.com/2013/09/30/web-application-protection/

https://developer.tizen.org/documentation/guides/native-application/security/key-manager

https://developer.tizen.org/documentation/guides/native-application/security/key-manager

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Secure-storage

https://wiki.tizen.org/wiki/Security/Tizen_2.X_Secure-storage

http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-Content_Security_Framework.pdf

http://cdn.download.tizen.org/misc/media/conference2013/slides/TDC2013-Content_Security_Framework.pdf

https://www.youtube.com/watch?v=GtiAQOo4beg

https://www.youtube.com/watch?v=GtiAQOo4beg



https://developer.tizen.org/forums/general-support/tizens-content-security-framework

https://developer.tizen.org/forums/general-support/tizens-content-security-framework

[116] Security/tizen 2.x csr-framework. https://wiki.tizen.org/wiki/Security/Tizen_2.X_csr-framework.

[117] Porting guide/connectivity. https://wiki.tizen.org/wiki/Porting_Guide/

Connectivity.

[118] http://t3746.handhelds-tizen-general.pdatalk.info/in-wich-file-is-wlan-

password-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 rando-mization for mobile devices. In Proceedings of the fourth ACM conference on Wirelessnetwork security, pages 127–138. ACM, 2011.

[123] Joshua J Drake, Zach Lanier, Collin Mulliner, Pau Oliva Fora, Stephen A Ridley, andGeorg 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/dev-

guide/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. http://web.nvd.nist.gov/view/vuln/

detail?vulnId=CVE-2012-6459.

[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/how-

authentication-center-auc-works-in-gsm/.

114

https://wiki.tizen.org/wiki/Security/Tizen_2.X_csr-framework

https://wiki.tizen.org/wiki/Security/Tizen_2.X_csr-framework

https://wiki.tizen.org/wiki/Porting_Guide/Connectivity

https://wiki.tizen.org/wiki/Porting_Guide/Connectivity

http://t3746.handhelds-tizen-general.pdatalk.info/in-wich-file-is-wlan-password-saved-t3746.html

http://t3746.handhelds-tizen-general.pdatalk.info/in-wich-file-is-wlan-password-saved-t3746.html

https://wiki.tizen.org/wiki/Security/Tizen_2.X_ca-certificates

https://wiki.tizen.org/wiki/Security/Tizen_2.X_ca-certificates

https://wiki.tizen.org/wiki/Security/Tizen_2.X_cert-svc-ui

https://wiki.tizen.org/wiki/Security/Tizen_2.X_cert-svc-ui

https://developer.tizen.org/dev-guide/2.2.0/org.tizen.native.apireference/classTizen_1_1Shell_1_1LockManager.html#a59b473817e9dda49128f14ff3b1b19f5



https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.appprogramming/html/guide/shell/lock_screen.htm

https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.appprogramming/html/guide/shell/lock_screen.htm

http://www.samsung.com/in/support/skp/faq/1073648

http://www.samsung.com/in/support/skp/faq/1073648

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6459

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6459

https://bugs.tizen.org/jira/browse/TIVI-211

https://bugs.tizen.org/jira/browse/TIVI-211

http://www.slideshare.net/ajin25/hacking-tizen-the-os-everything-nullcon-goa-2015

http://www.slideshare.net/ajin25/hacking-tizen-the-os-everything-nullcon-goa-2015

https://coronalabs.com/

http://www.ubuntu.com/tablet

https://en.wikipedia.org/wiki/Cold_boot_attack

http://pages.cpsc.ucalgary.ca/~szrrizvi/cpsc329/t2.html

http://www.teletopix.org/gsm/how-authentication-center-auc-works-in-gsm/

http://www.teletopix.org/gsm/how-authentication-center-auc-works-in-gsm/

[136] Scott Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the key scheduling algorithmof 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 ofthe 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.

[140] Wpa supplicant.conf(5). https://www.freebsd.org/cgi/man.cgi?query=wpa_

supplicant.conf&sektion=5.

[141] wpa supplicant(8) - linux man page. http://linux.die.net/man/8/wpa_supplicant.

[142] wpa supplicant passphrase, can it be normal password? http://superuser.com/

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. HarveyMudd 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). http://www.oracle.com/us/technologies/linux/lxc-

features-1405324.pdf.

[149] Jerome Petazzoni. Lightweight virtualization lxc container. https://www.

socallinuxexpo.org/scale11x-supporting/default/files/presentations/

Jerome-Scale11x%20LXC%20Talk.pdf.

115

https://en.wikipedia.org/wiki/IEEE_802.11i-2004

https://www.freebsd.org/cgi/man.cgi?query=wpa_supplicant.conf&sektion=5

https://www.freebsd.org/cgi/man.cgi?query=wpa_supplicant.conf&sektion=5

http://linux.die.net/man/8/wpa_supplicant

http://superuser.com/questions/679956/wpa-supplicant-passphrase-can-it-be-normal-password

http://superuser.com/questions/679956/wpa-supplicant-passphrase-can-it-be-normal-password

http://people.redhat.com/tcameron/summit2010/selinux/SELinuxMereMortals.pdf

http://people.redhat.com/tcameron/summit2010/selinux/SELinuxMereMortals.pdf

https://www.thomas-krenn.com/de/wikiDE/images/c/cf/20121106-Lighweight_Virtualization_LXC_Best_Practices.pdf



http://www.oracle.com/us/technologies/linux/lxc-features-1405324.pdf

http://www.oracle.com/us/technologies/linux/lxc-features-1405324.pdf

https://www.socallinuxexpo.org/scale11x-supporting/default/files/presentations/Jerome-Scale11x%20LXC%20Talk.pdf



Date post:	18-Mar-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

June 2015 - GitHub · 1 Introduzione 1.1 Il mercato dei dispositivi mobili Il vertiginoso sviluppo...

Documents