Mobile Oss Analysis Report for the Computer Security Exam at the Politecnico Di Torino

Home , Crypto API (Linux), Disk encryption theory

Mobile OSs analysis Report for the Computer Security exam at the Politecnico di Torino

Alessio Canepa (207687) Andrea Marcelli (209051) tutor: Andrea Atzeni

June 2015

1 Indice

1 Introduzione6 1.1 Il mercato dei dispositivi mobili...... 6 1.2 Il problema della sicurezza...... 6 1.2.1 Diﬀerenze tra sicurezza su mobile e su ﬁsso...... 7 1.2.2 Obiettivi di un attacco...... 8 1.2.3 Canali di attacco...... 9 1.2.4 Esempio di malware: SimpLocker, un ransomware per Android...... 10 1.2.5 Proteggersi dagli attacchi...... 13 1.3 Il modello dell’analisi di sicurezza...... 14 1.4 Conclusioni...... 15

2 Ubuntu Touch 17 2.1 Modalitàdell’analisi di sicurezza...... 17 2.2 Introduzione...... 18 2.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 necessitàdi confinare le applicazioni in Ubuntu...... 23 2.5.2 Introduzione ad AppArmor...... 24 2.5.3 AppArmor profile...... 25 2.5.4 Policy Groups...... 26 2.5.5 Gestione autorizzazioni: Trusted Helpers...... 28 2.5.6 Condivisione contenuti: Content Hub...... 29 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 Certiﬁcati...... 37 2.11 Vulnerabilit`anote...... 38 2.12 Conclusioni...... 38

3 CyanogenMod 40 3.1 Modalitàdell’analisi di sicurezza...... 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 Tecniche di confinamento delle applicazioni...... 42 3.3.1 Il modello Android...... 42 3.3.2 Gestione dei permessi...... 43 3.3.3 Gestione privilegi di root...... 44 3.4 Store...... 45 3.5 Componenti di sicurezza aggiuntivi...... 45 3.5.1 Whisperpush...... 45 3.5.2 Protezione da remoto: Device Finder...... 46 3.6 Cifratura dati utente...... 48 3.7 Protezione dell’accesso...... 49 3.8 Conclusioni...... 50

3 4 Tizen 51 4.1 Modalitàdell’analisi di sicurezza...... 51 4.2 Introduzione...... 52 4.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 Tecniche di confinamento delle applicazioni...... 59 4.5.1 Smack - Simplified Mandatory Access Control Kernel...... 59 4.5.2 Smack in Tizen...... 62 4.5.3 UserID e GroupID...... 62 4.5.4 The three domain model...... 63 4.5.5 Cynara...... 64 4.5.6 Commenti sul modello del controllo degli accessi in Tizen...... 66 4.5.7 Il sistema dei privilegi...... 67 4.5.8 Firma delle applicazioni...... 69 4.5.9 Installazione delle applicazioni...... 70 4.5.10 Esecuzione delle applicazioni...... 71 4.5.11 Vasum...... 72 4.6 Criticitàprogettuali ed implementative delle applicazioni...... 74 4.6.1 Conversione automatica della applicazioni...... 74 4.6.2 WebGL...... 75 4.6.3 XSS...... 77 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.10 Protezione dell’accesso...... 91 4.11 Vulnerabilitànote...... 92 4.12 Analisi Sperimentale...... 93 4.12.1 Test Smack label...... 93 4.12.2 Test ASLR...... 93 4.12.3 Test DEP...... 94 4.13 Conclusioni...... 95

5 Conclusioni 96

6 Appendice 100 6.1 Memorizzazione dati critici...... 100 6.1.1 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 diverse innovazioni, permettendo di lanciare sul mercato numerosi dispositivi innovativi. I progressi sulla “portabilità”della tecnologia hanno giocato un ruolo essenziale: sono nati nuovi dispositivi tascabili che hanno permesso di soddisfare la crescente necessitàdi archiviazione di dati e di connettivitàin movimento. Il mercato dei dispositivi mobili, ha reso “portabili” gran parte delle funzionalitàfino a quel momento ristrette ai soli computer desktop, introducendo i nuovi smartphone, tablet e computer portatili, tutti dotati di caratteristiche necessarie per un costante utilizzo al di fuori dei tradizionali confini aziendali e domestici. Considerando i soli dispositivi in grado di connettersi ad internet, il loro numero ha recentemente superato quello della popolazione mondiale: i dati [1] stimano 7.3 miliardi di dispositivi contro 7.2 miliardi di persone. Di questi piùdi 1.2 miliardi sono telefoni cellulari e il loro numero è destinato a crescere, raggiungendo i 4 miliardi nel 2018 [2], con un forte sviluppo del mercato asiatico, soprattutto in Cina ed India. Sebbene il termine dispositivo mobile si riferisca ad un insieme di dispositivi molto vasto, come tecnologie wearable, smartphone, fotocamere ed altri, nel corso del report saràutilizzato per indicare solo i telefoni cellulari di ultima generazione (smartphone) ed i tablet. In modo simile a quanto accade nel mondo desktop, l’interfaccia utente, il supporto per le applicazioni e tutte le altre funzionalitàsono offerte da un sistema operativo. L’importanza acquisita negli ultimi anni dai dispositivi mobile rende necessario un’approfondita analisi delle soluzioni di sicurezza adottate dai diversi sistemi. Nelle successive sezioni saranno analizzate le principali differenze che caratterizzano il mondo mobile dal tradizionale desktop e le relative implicazioni di sicurezza. Saranno anche introdotti i principali obiettivi e vettori di attacco, le cui contromisure verrano successivamente analizzate per ciascun sistema operativo trattato.

1.2 Il problema della sicurezza

L’avanzamento tecnologico garantisce ai dispositivi mobili una capacitàcomputazionale sempre maggiore. Da un lato, combinata con veloci interfacce di connessione, ha reso i dispositivi mobili bersagli di attacco appetibili per l’utilizzo anche in contesti malevoli, come all’interno di botnet. Dall’altro, una maggior capacitàcomputazionale, unita alle caratteristiche di “porta- bilità”e semplicitàd’uso, ha contribuito ad offrire maggiori funzionalità agli utenti. Alcune di queste sono operazioni sensibili per la sicurezza e privacy degli utilizzatori. Ad esempio, molti dispositivi mobile permettono di eseguire operazioni delicate quali l’esecuzione di movimenti bancari o la gestione di servizi a pagamento. La loro diffusione ha ampliato enormemente il panorama degli utilizzatori, estesosi a quasi tutte le fasce di età. Oltre ad un incremento di utilizzo, si èassistito anche ad un aumento della fiducia nei download di contenuti provenienti da autori sconosciuti. A livello applicativo, la semplificazione della procedura di sviluppo, anche tramite l’introduzione di SDK evoluti, ha favorito la crescita delle applicazioni disponibili. Nel primo trimestre del 2014, i due maggiori store distributori di applicazioni (AppStore e GooglePlay) hanno to- talizzato globalmente circa 250 milioni di download. La ricerca di malware nel volume delle applicazioni esistenti, èdifficile. La sicurezza in ambito mobile èun problema importante, che richiede di essere adeguatamente affrontato: le previsioni di Infonetics Research prevedono un aumento dei relativi costi, con

6 Figura 1: Numero di minacce contro dispositivi mobili.1 una punta di 3.8 miliardi di dollari nel 2018, da confrontarsi con gli 1.3 miliardi del 2013 [3]. Un ulteriore dato significativo èquello riguardante la crescita di minacce, in particolare quelle finalizzate all’estorsione di denaro, come mostrato in Figura1.

1.2.1 Diﬀerenze tra sicurezza su mobile e su ﬁsso

La diversitàtra i dispositivi mobili ed i calcolatori tradizionali rende difficile la semplice migrazione delle soluzioni di sicurezza giàdisponibili, richiedendone la progettazione di nuove. Di seguito sono elencate le differenze tra il mondo mobile e fisso che maggiormente influiscono sul campo della sicurezza.

• Mobilità: i dispositivi mobili nascono per poter essere sempre trasportati con sé. Se lasciati incustoditi, sono soggetti a furto o ad accesso non autorizzato: ènecessario avere a disposizione nuovi sistemi per la protezione dell’accesso fisico.

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

• Scheda SIM: ènecessaria per il funzionamento degli smartphone ed oggi èpresente anche nella maggior parte dei tablet. Alla scheda SIM èassociato un credito telefonico, grazie al quale èpossibile usufruire di servizi a pagamento come telefonate, SMS e traffico dati. Se un attaccante riuscisse a prendere il controllo del dispositivo, potrebbe avere facile accesso a tali risorse economiche. Secondo alcune ricerche [4], il 50% del malware recente su mobile funziona in questo modo, essendo relativamente semplice per l’attaccante ottenere un profitto. Inoltre, poichédal punto di vista dell’operatore mobile i costi sono addebitati comunque all’utente finale, èdifficile differenziare i casi di sottrazione di denaro illecito da lecite spese.

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

7 • Capacitàcomputazionale e batteria: mediamente, smartphone e tablet non dispongono della stessa capacitàcomputazionale dei calcolatori fissi, soprattutto in termini di CPU e di disponibilitàdi memoria RAM. Nonostante i modelli piùperformanti possano comunque avere caratteristiche hardware confrontabili ad alcuni computer desktop, la scarsa autonomia della batteria èun altro fattore limitante. In ambito mobile, non èsemplice realizzare protezioni a livello software basate su processi in continua esecuzione e computazionalmente intesivi. Inoltre, questo punto èparticolarmente critico, poichéla durata della batteria èuna delle caratteristiche del dispositivo piùvalutate a livello commerciale. • Sensori: I dispositivi mobili sono in genere dotati di una vasta gamma di sensori che offrono diversi servizi. Il GPS, la fotocamera, il microfono e l’accelerometro sono i principali. Qualora un attaccante riuscisse ad aver accesso ai dati dei sensori, avrebbe a disposizione un’enormitàdi informazioni per monitorare di nascosto l’utente. Ad esempio, una ricerca [5] ha dimostrato come sia possibile ottenere i caratteri digitati su una tastiera attraverso il solo utilizzo dell’accelerometro.

1.2.2 Obiettivi di un attacco

Esistono diversi obiettivi di un attacco da cui utenti e dispositivi devono proteggersi. Di seguito sono elencati i principali:

• Accesso a dati privati. I dispositivi mobili sono un mezzo di archiviazione di materiale personale, quindi un bersaglio appetibile per ottenere informazioni private su un utente. Nel caso di smartphone: SMS, email, il log delle chiamate e dati di alcune applicazioni sono molto interessanti. Inoltre le informazioni potrebbero anche essere eliminate o mo- dificate. Un esempio èl’applicazione SpyPhone2, per Android ed iOS, che viene eseguita in background ed èin grado di fornire ad un utente remoto informazioni relative a SMS, chiamate, email, inviare fotografie, informazioni di localizzazione, registrare audio ed altre ancora. • Furto d’identità. Uno smartphone costituisce indirettamente una forma di autenticazio- ne del suo possessore grazie alle informazioni contenute, al contratto telefonico a cui è associato ed alle password che memorizza. • Overbilling. Con questo termine si indicano gli attacchi volti ad utilizzare il credito telefonico associato ad un dispositivo, ad insaputa dell’utente. Ad esempio, inviando SMS automaticamente o effettuando chiamate verso numeri a pagamento. • Estorsione di denaro. In questa categoria rientrano i ransomware, software malevoli che applicano delle limitazioni nell’utilizzo del dispositivo e successivamente richiedono il pagamento di un riscatto (ransom in Inglese) per rimuovere il blocco. Un esempio è SimpLocker [6], un ransomware per Android, responsabile di cifrare alcune file importanti e di impedire qualsiasi operazione sul dispositivo, reindirizzando l’utente sempre alla schermata di sblocco. Si rimanda ad un’analisi dettagliata in 1.2.4. • Lo sfruttamento della capacitàcomputazionale. Nonostante, come precedentemente detto, la capacitàcomputazionale di un dispositivo mobile non sia attualmente comparabile con quella di un calcolatore fisso, negli anni si èassistito ad una crescita della velocitàdella CPU e della disponibilitàdi memoria RAM. Combinata con collegamenti internet ad alta velocità,rende i dispositivi mobili molto appetibili per l’utilizzo in contesti malevoli, come ad esempio le botnet [7].

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

8 • Denial Of Service. Si tratta di un attacco che mira a generare un disservizio. In generale, `efacilmente 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, ﬁno al blocco del dispositivo da remoto.

1.2.3 Canali di attacco

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

Canali di comunicazione

• Servizi di rete mobile tradizionali come GSM, 3G, 4G. Esempi sono gli attacchi di overbilling per il cellulare Siemens S55 [8] o il buﬀer overﬂow negli MMS su Windows Mobile CE. 4.2 [9].

• Wi-Fi: il traffico di una rete Wi-Fi puòsempre essere sniffato. Il pericolo èmaggiore se la rete èpubblica oppure se la protezione adottata èdebole, come nel caso del protocollo WEP.

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

• USB: la connessione USB ècomunemente utilizzata per sincronizzare il dispositivo mobile con il PC. Viene anche utilizzata dagli sviluppatori come interfaccia per il debug delle applicazioni. La sua gestione èimportante: l’accesso fisico al dispositivo potrebbe permettere di ottenere informazioni riservate e di installare applicazioni malevoli.

Malware Il malware èun software progettato per eseguire un payload ostile, intrusivo o dannoso ad insaputa dell’utente. Attualmente il principale vettore di distribuzione del malware èInternet. Ad esempio, puòessere nascosto nel codice Javascript di una pagina web, in un applicazione scaricata o sotto forma di allegato di una email. Storicamente il malware viene classificato in [11] virus (un binario che mira ad infettare altri file, principalmente eseguibili), worm (caratterizzato da una diffusione ed evoluzione automatica), trojan (apertura di una backdoor), rootkits (exploit che permette di ottenere i privilegi di amministratore del sistema), ransomware (limitazione dell’accesso ai file del dispositivo con richiesta di riscatto). Tuttavia, èbene notare che le minacce moderne difficilmente possono essere classificate in una sola delle categorie sopra elencate in quanto frequentemente combinano piùvarianti. La somiglianza tra i sistemi operativi mobile con quelli tradizionali ha favorito la migrazione di software malevoli, inizialmente nati per essere eseguiti su PC, sui nuovi dispositivi. Tuttavia, la scarsa capacitàcomputazione e le limitazioni imposte dalla batteria rendono le classiche soluzioni Anti-Virus per desktop non praticabili su smartphone e tablet. Nuove soluzioni, basate sull’installazione delle sole applicazioni firmate da una Trusted Chain e di framework di scansione ottimizzati, saranno analizzate in dettaglio nel corso del report.

9 Figura 2: Il messaggio visualizzato da SimpleLocker. 3

1.2.4 Esempio di malware: SimpLocker, un ransomware per Android

Viene di seguito analizzato SimpLocker, un ransomware per Android. Nonostante attualmente sia diﬀuso solo per la piattaforma Android, le tecniche impiegate sono generali ed applicabili anche ad altri sistemi operativi mobile.

Introduzione Verso metàdel 2013 Symantec ha rilevato Android Defender (rinominato dalle aziende di Anti-Virus Android.Fakedefender), il primo ransomware per Android [12]. Si tratta di un’applicazione che, fingendo di effettuare una scansione e rilevando minacce non esistenti, blocca il dispositivo fino al pagamento di un riscatto. Il ransomware èun tipo di malware ben noto che impedisce all’utente l’accesso ai propri file fino al pagamento di un riscatto. Un anno dopo, a metàdel 2014, Symantec ha individuato una nuova variante di ransomware per Android, conosciuta come SimpLocker, che impedisce l’accesso ai file del dispositivo cifrandoli. L’applicazione che distribuiva il malware in questione è Sex Xonix, un gioco all’epoca disponibile su Google Play Store. SimpleLocker [13] èuna versione semplificata di una famiglia di ransomware molto diffusi sulla piattaforma Windows desktop: Dirty Decrypt, CryptoLocker, CryptoWall, CryptoDefense, TorrentLocker e Cryptographic Locker. Il malware èdisponibile su Android in differenti versioni: 30 sono le varianti conosciute dalle aziende Anti-Virus, rappresentate tutte con il nome di Android.SimpLocker. Una volta che l’applicazione viene scaricata ed installata sul dispositivo mobile, il malware visualizza un messaggio a tutto schermo, riportato in Figura3, indicando che il telefono è stato 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 ènecessario effettuare un pagamento. Il messaggio puòessere chiuso, ma viene immediatamente visualizzato nuovamente se l’utente tenta di lanciare un’altra applicazione. Per una maggiore intimidazione, alcuni versioni utilizzano anche la fotocamera del telefono per catturare la faccia dello sfortunato possessore e minacciano di mandarla ovunque l’autore del malware lo ritenga necessario. Diverse versioni del malware differiscono nel messaggio intimidatorio, nell’ammontare dell’estorto e sul metodo di pagamento. Durante l’installazione l’applicazione richiede i seguenti permessi [14]:

• Accesso ad Internet illimitato.

• Permesso per monitorare lo stato della rete.

• Accesso allo stato del telefono ed il suo ID.

• Permesso di eseguire applicazioni all’avvio del dispositivo.

• Divieto di impostare il telefono in modalit`asleep.

• Accesso in lettura SD card.

• Accesso in scrittura su SD card.

Nonostante una lunga lista di permessi richiesti, inusuale per un gioco, non sono inclusi quelli piùallarmanti, come la possibilitàdi effettuare chiamate e di mandare SMS, inoltre non vi èla richiesta dei privilegi di root. E` comprensibile, quindi, che gli utenti continuassero con l’installazione dell’applicazione.

I componenti Il malware `ecomposto da cinque componenti:

• Una Main Activity: si attiva quando l’utente tocca l’icona sullo schermo. Lo scopo principale `equello di bloccare lo schermo, visualizzare un messaggio intimidatorio ed eseguire il servizio MainService. Tutti i messaggi intimidatori sono memorizzati nel ﬁle APK come stringhe di testo ed lo schermo viene bloccato intercettando se vengono premuti i tasti di Home, Indietro e Menu.

• Due BroadcastReceiver: ServiceStarter e SDCardServiceStarter. Il primo viene eseguito quando il sistema viene avviato. Il secondo si avvia quando `edisponibile una scheda SD e si occupa di cifrare i ﬁle.

• Due Service: MainService and TorService. Il primo si occupa di fornire le funzionalit`adi base del malware. TorService `eresponsabile della comunicazione con il command server tramite la rete Tor.

Ricerca e Cifratura dei File Se una scheda di memoria SD èpresente nel telefono, il servizio SDCardServiceStarter si occupa della ricerca e cifratura di tutti i file con le seguenti estensioni: .3gp, .avi, .bmp, .doc, .docx, .gif, .jpeg, .jpg, .mkv, .mp4, .pdf, .png, .txt. I file vengono cifrati usando Java Cryptography Extension (JCE) che implementa gli algoritmi di crittografia di base. Il malware utilizza un algoritmo di cifratura simmetrica AES 256 bit, con modalitàCipher Block Chaining (CBC). La chiave viene generata a partire da una stringa di testo, memorizzata nel programma, di cui viene effettuato un hash con algoritmo SHA-256. La stringa èlunga 12 caratteri e differisce nelle varianti del malware.

11 Figura 3: Prima e dopo la cifratura dei ﬁle.4

Essendo AES un algoritmo di cifratura simmetrica, cifratura e decifratura usano la stessa chiave. Analizzando il codice del malware èpossibile ottenere le istruzioni utilizzate per generare la chiave ed utilizzarle per decifrare i file, senza la necessitàche il server di controllo malevole, Command&Control, invii il comando di sblocco. Una volta che i file sono stati cifrati, il malware aggiunge l’estensione .enc ai file cifrati, li scrive sulla scheda SD ed elimina i file originali, come visibile in Figura3. In confronto, CryptoLocker [15], la versione desktop del malware, fa uso di una maggiore complessitànella fase di cifratura: impiega AES per cifrare le informazioni iniziali e RSA, un algoritmo di cifratura asimmetrico, per cifrare i file del dispositivo. La chiave privata viene salvata nel Command&Control server, rendendo quasi impossibile il recupero dei file senza pagamento del riscatto. Per poter confrontare con maggiore dettaglio le tecniche usate nelle due versioni di malware, di seguito sono elencati i principali passaggi della tecniche di cifratura usati da CryptoLocker:

• Il malware ottiene delle informazioni sul calcolatore della vittima e le cifra utilizzando una chiave AES-256 bit generata randomicamente [16]. • La chiave AES viene cifrata utilizzando RSA (1024 o 2048 bit a seconda della versione del malware) con la chiave pubblica hardcoded del server Command&Control. • Le informazioni sul computer della vittima (cifrate con AES) e la chiave AES (cifrata con RSA) vengono inviate al server. • Il server decifra la chiave AES utilizzando la propria chiave privata ed in seguito decifra anche le altre informazioni sulla vittima. • Il server genere una coppia di chiavi asimmetriche RSA (2048 o 4096 bit a seconda delle versioni), che saranno utilizzate per la cifratura dei ﬁle 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-256 bit precedentemente inviata.

Connessione con il Command Server La connessione con la rete Tor5 assicura la comunicazione con il Command&Control, il server malevole che viene ospitato nel dominio “.onion”, rendendo difficile l’identificazione del proprietario. Il nome del server viene specificato direttamente nel programma, differenti versioni utilizzano nomi diversi. Dopo aver stabilito una connessione, il malware ottiene le informazioni sul telefono (IMEI, numero di telefono, modello, versione del sistema operativo) e le trasmette al command server per determinare se il pagamento èstato effettuato. In seguito alla conferma del pagamento, un messaggio di risposta dal server (stop) permette di sbloccare lo schermo e decifrare i file precedentemente cifrati.

Rimozione dell’applicazione malevole In alcuni dispositivi Android, il malware puòessere rimosso velocemente disinstallando l’applicazione Sex Xonix, dopo aver riavviato il dispositivo. Tuttavia, nella maggior parte dei casi l’applicazione viene caricata cos`ıvelocemente dal sistema da impedirne la rimozione. La maggioranza dei dispositivi Android fornisce un’opzione per il boot del sistema operativo (OS) in Safe Mode. Questo permette di caricare solo le funzionalitàdi base dell’OS ed impedisce che applicazioni di terze parti vengano eseguite. Android.Simplocker puòessere rimosso eseguendo il sistema operativo con questa opzione. Se dopo l’installazione dell’applicazione malevole il dispositivo viene immediatamente spento, si puòprevenire che molti file vengano cifrati. In seguito si puòprocedere alla disinstallazione, come precedentemente spiegato, o ad un factory reset, riportando il dispositivo alle impostazioni di fabbrica. Tutti i file cifrati, possono essere decifrati in quanto la chiave utilizzata dall’algoritmo di cifratura simmetrica viene salvata all’interno del malware. Tuttavia non risulta essere un’operazione semplice per la maggioranza degli utenti che non sono familiari con gli algoritmi di cifratura.

Conclusione Android.Simplocker èil primo ransomware conosciuto per Android che cifra i file, rendendone impossibile l’accesso. Nonostante questa versione del malware sia molto semplice, soprattutto se confrontata con Cryptolocker, vi èmolto spazio per miglioramenti futuri.

1.2.5 Proteggersi dagli attacchi

La protezione dalle minacce descritte in 1.2.2e 1.2.3 pu`oessere implementata su diversi livelli, di seguito elencati.

• Rete. A livello di rete èpossibile monitorare il traffico alla ricerca di anomalie ed implementare alcuni filtri basati sul riconoscimento di patterns malevoli. Nel caso degli SMS, ad esempio, si potrebbe sospettare un traffico anomalo nella quantitàdi essi, proveniente dallo stesso numero telefonico.

• Il sistema operativo. In ambito mobile rappresenta il tipo di protezione pi`uimportante. I sistemi operativi mobile limitano l’adozione di sistemi di sicurezza “detection based” in favore di soluzioni di tipo “prevention based”. I primi sono dispendiosi nei consumi, i secondi mirano a prevenire ed, in caso, a limitare i danni inﬂitti da un software malevole

5https://www.torproject.org

13 o da altri attacchi precedentemente descritti in 1.2.3. La strategia di prevenzione si concretizza soprattutto nella realizzazione del “Conﬁnamento delle applicazioni”, uno dei punti centrali dell’analisi (sezioni 2.5, 3.3, 4.5).

• Store. E` il negozio virtuale per la distribuzione di applicazioni. Attualmente ogni sistema operativo ha il proprio store ufficiale, ma sono presenti anche versioni multipiattaforma, ad esempio per la distribuzione di applicazioni in tecnologia Web. In ambito mobile rappresenta il primo filtro per evitare la diffusione di applicazioni malevoli, grazie ad un processo di revisione che puòessere anche completamente automatizzato. Nelle sezioni 2.6, 4.7 verranno trattate in dettaglio le diverse soluzioni adottate per ciascun sistema operativo analizzato.

• Utente. Parte degli attacchi non sfrutta falle tecnologiche dei dispositivi attaccati, ma utilizza tecniche di social engineering che portano l’utente ad eseguire operazioni dannose per la sua privacy o per l’integritàdel sistema operativo. Prevenire questi problemi èuna sfida piùa livello sociale che tecnologico: sono necessarie campagne di informazione e di sensibilizzazione degli utenti verso il problema della sicurezza, affinchésiano consape- voli delle sempre crescenti situazioni di rischio legate ad un uso non coscienzioso di uno smartphone. Tuttavia, i sistemi operativi mobile possono offrire un certo livello di protezione attraverso notifiche sui possibili rischi legati ad alcune funzionalità,sull’utilizzo di impostazioni non sicure o addirittura in alcuni casi, impedendo determinate azioni.

Nel corso del report verranno analizzate nel dettaglio le soluzioni di sicurezza oﬀerte a livello di sistema operativo, store ed utente. Le operazioni di monitoring della rete sono a carico dell’operatore e dell’amministratore di rete, esulando pertanto dagli scopi di questo documento.

1.3 Il modello dell’analisi di sicurezza

Nel report saranno analizzati due sistemi operativi emergenti, Ubuntu Touch e Tizen ed il custom firmware di Android CyanogenMod. Al fine di rendere il documento piùomogeneo, l’analisi èstata condotta secondo un modello comune. Nonostante la diversitàdei sistemi analizzati, sono state selezionate alcune macrocategorie, di seguito dettagliate, in modo da facilitare l’operazione di confronto tra le soluzioni adottate in ciascun prodotto.

1. Modalit`adell’analisi di sicurezza: descrizione del procedimento adottato e delle fonti impiegate per analizzare il sistema operativo.

2. Introduzione

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

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

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

14 6. Criticitàprogettuali ed implementative delle applicazioni: valutazione di possibili pe- culiaritàprogettuali o implementative che introducono debolezze nella sicurezza delle applicazioni. 7. Store: analisi del negozio virtuale, nel caso in cui sia disponibile, per la distribuzione di applicazioni per dispositivi mobili. Il servizio generalmente permette di navigare tra le applicazioni compatibili con il proprio dispositivo e di scaricarle direttamente sullo smartphone o tablet, sia gratuitamente, che a pagamento. Si vogliono analizzare le possibili funzioni offerte, tra cui quella di filtrare la pubblicazione di applicazioni sulla base di un processo di revisione al fine di limitare la diffusione di applicativi malevoli o non adatti, nei contenuti, per gli utenti. 8. Cifratura: eventuali funzionalitàfinalizzate a limitare l’esposizione e la perdita di dati sensibili memorizzati all’interno dei terminali, in particolare a seguito della compromissione fisica di un dispositivo. 9. Componenti di sicurezza aggiuntivi: analisi di eventuali soluzioni di sicurezza addizionali, specifiche di ciascun sistema operativo. 10. Protezione dell’accesso: analisi dei meccanismi disponibili per la protezione dell’accesso fisico, il primo livello di protezione applicabile sui dispositivi mobili. E` finalizzato ad ini- bire l’uso non autorizzato in caso di smarrimento o furto ed a proteggere i dati contenuti al suo interno. In questo contesto rientrano l’impiego della password impostabile dall’u- tente ed il blocco automatico del dispositivo dopo un certo periodo di inattività.Misure addizionali riguardano la possibilitàdi effettuare un reset hardware o la cancellazione dei dati da remoto. 11. Vulnerabilitànote: eventuali falle di sicurezza note pubblicamente, alle quali èstato assegnato un Identificatore CVE (Common Vulnerabilities and Exposures). 12. Analisi sperimentale: eventuale utilizzo dell’emulatore o di un dispositivo fisico per provare le nozioni acquisite, testare le impostazioni di sicurezza insieme a possibili debolezze del sistema operativo. 13. Conclusione: note conclusive sull’analisi del sistema operativo. Punti di forza, debolezze, migliorie. Confronto delle soluzioni adottate con quelle offerte nel panorama della sicurezza mobile.

L’analisi èstata condotta in collaborazione con il Security Lab di “Telecom Italia Information Technology”. Si ringraziano Roberta D’Amico, Dario Lombardo per il supporto offerto. In accordo con le loro esigenze, si èdeciso di analizzare i tre sistemi operativi con un livello di dettaglio crescente secondo l’ordine: CyanogenMod, Ubuntu Touch e Tizen. Questa scelta è dettata anche dal livello di interesse e particolaritàdei sistemi in questione. Tizen èindubbia- mente il piùinteressante ed innovativo nelle soluzioni di sicurezza. Ubuntu Touch èun ramo di Ubuntu, che si vuole aprire al mondo mobile conservando la struttura della versione desktop. Infine, CyanogenMod èuna variante di Android, che rilassa alcuni stretti vincoli di sicurezza a vantaggio di maggiori funzionalità.

1.4 Conclusioni

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

15 disponibilitàdi una connettivitàquasi sempre presente, rende i dispositivi mobili soggetti a diversi tipi di attacco, che possono arrecare un danno economico, materiale, o violare la privacy dei loro possessori. E` evidente che siamo all’inizio di un’era in cui gli attacchi saranno sempre piùsofisticati. Progettare nuove soluzioni di sicurezza ad hoc èuna sfida tanto necessaria quanto difficile: l’adozione delle stesse misure adottate su calcolatori classici èostacolata dalle limitate risorse che i dispositivi mobili offrono, in termini di capacitàcomputazionale, ma soprattutto per l’autonomia di carica. In questo contesto, èfondamentale il ruolo del sistema operativo mobile, che racchiude quasi interamente le funzioni di sicurezza adottabili.

16 2 Ubuntu Touch

Figura 4: Schermata home di Ubuntu Touch6

2.1 Modalit`adell’analisi di sicurezza

Si analizzano ora le caratteristiche di sicurezza di Ubuntu Touch. L’analisi èstata condotta principalmente sulla base della documentazione ufficiale del sistema operativo presente online. Oltre a ciò,la natura open source di Ubuntu Touch ha consentito di esplorare le discussioni pubbliche degli sviluppatori sulle piattaforme online di codesharing, tra cui Launchpad7. Si èanche preso diretto contatto con alcuni sviluppatori tra cui Marc Deslauriers, esperto di sicurezza in Canonical8 e uno dei piùcontribuenti sviluppatori di Ubuntu, il quale ha fornito consigli su come affrontare l’analisi e chiarimenti. Infine, èstato utilizzato l’emulatore ufficiale di Ubuntu Touch9 al fine di poter testare la navigazione attraverso le funzionalitàdel sistema. In generale, si vuole specificare che l’attuale condizione di sistema operativo neonato ha reso particolarmente difficile la ricerca di informazioni. La documentazione ufficiale cambia di mese in mese e contiene a volte informazioni non aggiornate. Alcune delle strategie di sicurezza da

6Sorgente immagine: https://lwn.net/Articles/540146/. 7www.launchpad.net 8Canonical `ela compagnia che sta dietro allo sviluppo di Ubuntu 9Al momento estremamente limitato.

17 adottare sono attualmente ancora in discussione. Lo stato dell’arte, in termini di documentazione e analisi, relativo a Ubuntu Touch èestremamente limitato se non inesistente. Secondo le nostre ricerche, la presente analisi rappresenta il primo documento che riunisce in modo ordinato i diversi aspetti di sicurezza di questo sistema operativo. Le suddette ragioni, unite alla difficoltàdi reperire un dispositivo compatibile con Ubuntu Touch (il primo modello di smartphone con Ubuntu Touch preinstallato èuscito a inizio 2015), hanno portato ad optare per un’analisi di tipo documentativa e non sperimentale. Poiché,come saràmostrato nella sezione 2.3, l’architettura software di tale sistema operativo coincide in gran parte con quella di Ubuntu Desktop, ed essendo una completa analisi della sicurezza di Ubuntu al di fuori degli intenti di questo report, si èdeciso di analizzare gli aspetti del sistema operativo che hanno maggior rilevanza ai fini dell’utilizzo in ambiente mobile.

2.2 Introduzione

Ubuntu Touch èuna nuova distribuzione di Ubuntu volta al mondo dei dispositivi mobile [17]. Si tratta di un sistema operativo per smartphone e tablet, con un’interfaccia che ricorda molto Ubuntu Desktop nelle forme e colori. Sebbene la versione desktop e mobile siano al momento distribuite distintamente, in realtàèbene chiarire che dal punto di vista architetturale non si tratta di due sistemi distinti [18]: Ubuntu Touch èdi fatto Ubuntu 14.04, a cui comunemente viene aggiunto il suffisso Touch nel caso sia utilizzato in ambiente mobile10. Si spiega meglio l’origine di questa scelta e quale innovazione porta con se.

2.2.1 Poca integrazione tra S.O. mobili e ﬁssi

I primi telefoni cellulari erano dotati di capacitàcomputazionale e funzionalitàimparagonabili a quelle dei sistemi fissi. Per questo motivo, il loro campo di utilizzo èrimasto per anni ben distaccato da quello dei comuni calcolatori. Come presentato nell’introduzione, l’era degli smartphone sta annientando queste differenze. Ad oggi èpossibile fare coi nostri smartphone quasi tutto ciòche i sistemi desktop permettono. Eppure, nonostante queste differenze in termini di utilizzo stiano scomparendo, le strutture software che li governano ereditano dal passato profonde differenze che ostacolano una totale integrazione dei due sistemi. Difficilmente si puòiniziare a scrivere un file su desktop per poi proseguire da smartphone o viceversa. Nonostante i moderni sistemi Cloud cerchino di ovviare a questo problema (si veda ad esempio Google Drive), la strada pare ancora lunga, e porta con sédiverse problematiche legate alla necessitàdi una connessione internet. Finchédispositivi mobili e fissi erano dedicati a scopi distinti, tale mancanza di integrazione non rappresentava un problema. Oggi che èpossibile gestire con entrambi le stesse cose, il tema sta acquisendo sempre maggiore rilevanza.

2.2.2 Convergenza

La soluzione a questa poca integrazione proposta da Canonical, il team di sviluppo di Ubuntu, si chiama convergenza e si basa su un’idea molto innovativa. Dal momento che i moderni dispositivi mobili possono avere le caratteristiche sufficienti per eseguire un sistema operativo desktop, si èpensato di lasciarsi alle spalle la storica divisione tra i due mondi, portando su tali dispositivi lo stesso Ubuntu desktop. Il kernel Linux si adatta bene a diversi tipi di architetture hardware e, come l’esperienza Android dimostra, puòfacilmente essere utilizzato anche su questi

10La terminologia “Ubuntu Touch” pare addirittura non essere uﬃcialmente riconosciuta dagli sviluppatori, sebbene sia comunemente utilizzata.

18 device. Tale operazione ha indubbiamente richiesto alcune modifiche, specialmente a livello di gestione dell’interfaccia (resa in grado di adattarsi a schermi piccoli e touch screen) e dei driver, che saranno analizzate nella sezione 2.3. Guardando al futuro, l’idea della convergenza èdi unificare il mondo mobile e desktop, 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 computer fisso e mostrare all’utente un classico sistema operativo desktop. Ad oggi la convergenza non è stata ancora portata a termine, e Ubuntu Touch (o meglio, l’adattamento di Ubuntu ai dispositivi mobili) èancora da considerarsi un sistema in via di sviluppo. Al momento èpossibile installarlo solo su alcuni device di casa Google (Nexus 4, Nexus 7, Nexus 10) e, da Febbraio 2015, èin commercio il primo smartphone (Aquaris E4.5) con Ubuntu Touch preinstallato11. Fino a Gennaio 2015, sulla pagina web ufficiale del progetto si leggeva che la convergenza sarebbe giunta a completamento con Ubuntu 16.04 LTS. Ora tale pagina èstata rimossa per motivi a sconosciuti, ma si suppone che il progetto sia ancora in atto.

2.3 Architettura

Come detto precedentemente, l’architettura di Ubuntu Touch coincide quasi interamente con l’architettura di Ubuntu 14.04 LTS. In Figura5 se ne ha una rappresentazione schematica. Si noti come si distinguono 2 macro-blocchi: il kernel Linux e lo strato Ubuntu. Il kernel inizialmente incluso era la versione 3.13, ma `estato aggiornato alla 3.16 con il rilascio di Ubuntu 14.04.2 nel Febbraio 2015. Si descrivono ora le componenti di pi`ualto livello.

2.3.1 LXC - Linux Container

Un LXC (Linux Container) èun ambiente per la virtualizzazione a livello di sistema operativo, che permette l’esecuzione di diversi ambienti Linux isolati tra loro (detti appunto containers) all’interno di un singolo sistema Linux reale ospitante. Per una trattazione piùapprofondita si faccia riferimento all’appendice 6.6. Si mostrano le ragioni della presenza di un LXC nel caso in questione. Ubuntu Touch sta indubbiamente entrando nel mercato in ritardo rispetto ai propri concorrenti. Voler sviluppare un sistema in grado di essere eseguito sul maggior numero di dispositivi possibile richiede di avere a disposizione per ciascuno di essi i driver di basso livello necessari. Come dichiarato da Ricardo Salveti all’Embedded Linux Conference 2014, chiedere ai produttori di dispositivi di rilasciare i driver compatibili con Ubuntu sarebbe stato impossibile. Ubuntu Touch risol- ve questo problema eseguendo all’interno di un LXC l’Android HAL (Hardware Abstraction Layer), al fine di utilizzarne i driver e alcuni demoni necessari per la gestione dell’hardware del dispositivo sottostante. Come si èdetto, il container deve essere ospitato da un altro sistema Linux based, nel nostro caso Ubuntu. Poichénel nostro caso l’LXC contiene i driver necessari alla comunicazione con il dispositivo, il suo avvio avviene durante le primissime fasi del boot. Non appena il sistema èpronto, l’LXC viene avviato e genera al suo interno il proprio file system. Al termine del suo caricamento, il processo di boot standard puòproseguire ed avviare tutte le funzionalitàdi più alto livello. Da questo momento in avanti, le applicazioni possono dialogare con il container, e

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

19 Figura 5: Architettura Ubuntu Touch 12. dunque con l’hardware sottostante, tramite libhybrids13, che funge da strato di comunicazione tra i due [19].

2.3.2 Mir

Mir `eil display server. E` stato sviluppato per rimpiazzare il vecchio X Window System e supportare lo sviluppo di Unity 8, la nuova generazione di Unity user interface. In quanto display server, esso controlla e gestisce a basso livello l’integrazione delle parti della GUI. Ad esempio, gestisce il mouse e aiuta a combinare i movimenti del mouse con il cursore e gli eventi di interfaccia che il movimento del cursore causa. La Figura6 mostra alcune delle funzionalit`a di Mir.

2.3.3 Unity 8

Unity8 èla shell grafica utilizzata. Fornisce gli strumenti di interfaccia utili ad utilizzare il sistema nel modo piùuser-friendly possibile. Consente operazioni come l’apertura, chiusura, movimento, ridimensionamento delle finestre, o il cambio di focus tra queste. Le modifiche avvenute da Unity 7 a Unity 8 sono un passo fondamentale verso la convergenza. Unity 8 èstata infatti progettata nell’intento di avere un’unica implementazione che potesse gestire un’interfaccia grafica in grado di adattarsi perfettamente ad una vasta varietàdi schermi, in senso di forme e dimensioni: smartphone, tablet, TV, desktop. Inoltre, sempre pensando ad un utilizzo nel contesto “converged”, Unity 8 èstata alleggerita rispetto alla versione precedente, al fine di essere adatta ad un hardware piùlimitato. Unity 8 èstata sviluppata in gran parte

13Hybris o libhybris `eun livello di compatibilit`aper computer su cui sono eseguite distribuzioni Linux, basato sulla libreria GNU C, ed ha lo scopo di rendere possibile utilizzare software scritto per sistemi Linux Bionic-based Linux, che includono principalmente librerie Android e driver dei dispositivi. 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 di un linguaggio basato sull’integrazione di JavaScript e Qt per la progettazione di applicazioni con interfacce di grande impatto visivo [21]. Qt `euna libreria cross-platform, largamente utilizzata nello sviluppo di applicazioni software con interfaccia graﬁca [22].

2.3.4 Applicazioni

Tipologie Le applicazioni, cos`ıcome lo stesso Unity, si appoggiano su Mir e Qt. Possono essere scritte in QML o HTML5. Mentre le applicazioni QML sono necessariamente Local, ovvero il cui codice risiede in locale, le applicazioni HTML 5 possono essere sia Local che Hosted, ovvero residenti su website remoti ed eseguite dal browser. Per richiamare l’espressione utilizzata nella documentazione ufficiale, le applicazioni Web-based (scritte in HTML5) e quelle native (QML) sono considerate “equal citizens”, ovvero condividono lo stesso modello e possono (a meno di restrizioni che vedremo in seguito) accedere allo stesso insieme di API del dispositivo. Le applicazioni HTML 5 sfruttano Apache Cordova. Si tratta di un insieme di API, che permettono ad una applicazione di accedere tramite JavaScript alle funzionalitànative del dispositivo quali la fotocamera e l’accelerometro. Combinate con un UI framework, nel nostro caso Qt, permettono di sviluppare un’applicazione utilizzando solo HTML, CSS, e JavaScript. E` previsto anche il supporto per applicazioni scritte in C++, anche se èuna pratica meno frequente [23].

21 Distribuzione Tradizionalmente il software per Ubuntu èdistribuito attraverso gli Ubuntu archives. Tale modello èbasato sulla fiducia, barriere all’ingresso e tempi lunghi. Per avere il permesso di pubblicare un pacchetto all’interno di tale archivio, uno sviluppatore deve dimostrare affidabilitàcontribuendo molto all’interno della community. Imparare a creare e modificare tali pacchetti e renderli conformi alla pubblicazione negli Ubuntu archive ècom- plesso, richiede tempo e rappresenta pertanto una grossa difficoltà. Inoltre, tali archivi sono aggiornati solo con le nuove release di Ubuntu, pertanto i tempi richiesti per la pubblicazione o l’aggiornamento di un’applicazione sono particolarmente lunghi. Questo processo lungo e complesso, unito a continui controlli di sicurezza sui pacchetti, garantisce un archivio software di cui gli utenti si possono fidare, ma non rappresenta un canale tramite cui gli sviluppatori possono portare agli utenti rapidamente le nuove versioni del proprio software. L’obiettivo della convergenza e, in generale, la nuova apertura verso il mercato dei dispositivi mobili, ha reso necessaria l’adozione di un nuovo sistema di distribuzione delle applicazioni. Si vuole avere un modello di App store, semplice, rapido, dinamico, adatto alla distribuzione di un elevato numero di applicazioni, in cui anche piccoli sviluppatori (in numero sempre crescente) possano pubblicare le proprie applicazioni e gli aggiornamenti, in modo che siano subito disponibili agli utenti finali. Inoltre, si vuole aggiungere supporto per la creazione di applicazioni che saranno eseguite sotto confinamento. A tal scopo, parallelamente ai tradizionali Ubuntu archives, èstato aggiunto uno store speciale (al momento non accessibile da browser) dedicato ai cosiddetti Click Packages. Si tratta di un nuovo formato di packaging utilizzato in Ubuntu Touch e, a partire da Ubuntu 14.10, sulla versione Desktop. I Click package semplificano notevolmente il lavoro dello sviluppatore. Pos- sono essere creati grazie ad una procedura automatizzata tramite l’Ubuntu SDK, che permette inoltre la specifica delle impostazioni di confinamento. La procedura di caricamento online dei Click package richiede pochi minuti attraverso il portale“My Apps” di Ubuntu, e li rende quasi immediatamente disponibili agli utenti. Dettagli saranno discussi in 2.6. Non esistendo ancora un nome specifico per lo store online che distribuisce i Click packages, d’ora in avanti lo denoteremo con “App store”, al fine di distinguerlo dai tradizionali repository (Ubuntu archives).

Applicazioni trusted e untrusted Le applicazioni possono essere distinte in due macro gruppi: untrusted e trusted dall’OS. Le applicazioni untrusted sono quelle scaricate dall’App store, per le quali il processo di pubblicazione èpiùsemplice. Tali App sono obbligatoriamente confinate da un profilo AppArmor (vedremo di cosa si tratta in 2.5). I controlli dello store su queste App possono essere, sotto opportune condizioni che vedremo in 2.6, automatici. Le App non fidate possono accedere solo ai propri dati e a quanto espressamente concesso dall’utente, non possono accedere a funzioni privilegiate del OS, néa particolari API come quelle per la telefonia. Con l’autorizzazione dell’utente, esse possono accedere ad API sensibili come la localizzazione o online accounts. Tipicamente non sono supportate da Ubuntu o Canonical. Le applicazioni fidate sono invece quelle installate come parte integrante del sistema operativo o distribuite da Ubuntu/Canonical. Di norma queste applicazioni non sono eseguite confinate. Tali applicazioni possono tipicamente accedere ad ogni risorsa o dato disponibile all’interno della sessione dell’utente. Hanno accesso limitato ai servizi e dati di sistema secondo il sistema tradizionale di permessi Unix. Sono supportate da Ubuntu e/o Canonical e di norma costantemente aggiornate.

22 2.4 Modello di sicurezza del sistema operativo

Garantire massima sicurezza `euno dei principi fondamentali dello sviluppo di Ubuntu Touch. Si riassumono brevemente i punti chiave su cui si basa il modello di sicurezza adottato, indicando in quali sezioni di questo report sono analizzati.

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

• Confinamento applicazioni (2.5): èil meccanismo chiave con cui si applica la sicurezza. Consiste nella definizione di un profilo per ogni applicazione, che ne specifica i permessi.

– Controllo accesso al file system (2.5.3): tramite il profilo sopra detto, èpossibi- le specificare singolarmente a quali percorsi del file system una applicazione può accedere. – Protezione accesso a sensori e particolari tipi di dato (2.5.4e 2.5.5): anche per i sensori e dati quali la musica, galleria fotografica, calendario ecc... èpossibile definire regole di accesso individuali. – Protezione condivisione dati tra applicazioni(2.5.6): nonostante il confinamento, al fine di migliorare l’esperienza utente le applicazioni devono essere in grado di scambiare dati tra loro, e ciòdeve avvenire in modo sicuro.

• Controllo a livello di store (2.6)

– Verifica applicazioni: al fine di garantire un App store funzionale e al contempo sicuro, ènecessario affiancare processi di revisione delle App automatici ad altri manuali. – Firma applicazioni: il dispositivo deve poter scaricare applicazioni solo da fonti attendibili e verificarne l’autenticità.

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

• Cifratura dati utente(2.8): consente di proteggere la segretezza dei dati anche nel caso in cui protezioni a livello software (di sistema operativo) non fossero eﬃcaci.

• Protezione dell’accesso(2.9): `eil sistema base con cui viene impedito lo sblocco del dispositivo ad un utente non autorizzato.

2.5 Tecniche di conﬁnamento delle applicazioni

2.5.1 La necessit`adi conﬁnare le applicazioni in Ubuntu

L’introduzione di un App store per la distribuzione dei Click package introduce alcune problematiche di sicurezza: il processo semplificato puòfacilitare la pubblicazione di malware all’interno dello store, oppure permettere che applicazioni con falle di sicurezza arrivino direttamente agli utenti. Ubuntu deve essere pronto ad ospitare in modo sicuro grandi quantitàdi software non fidato. Ciòimplica la necessitàdi confinare le applicazioni. Tecniche di confinamento delle applicazioni sono di uso comune in tablet e smartphones. Da quanto detto in precedenza sulla convergenza, dovrebbe essere chiaro che, nel nostro caso, le soluzioni adottate per confinare le applicazioni sono state progettate non in modo specifico per dispositivi mobili, ma per un

23 sistema operativo congiunto, in grado di essere eseguito su smartphones, tablets, smart TV e desktops. Tali soluzioni, inoltre, necessitano di essere facilmente compatibili con applicazioni giàesistenti. Un’applicazione confinata deve avere il permesso di leggere e scrivere dati solo da locazioni che sono state precedentemente approvate dall’utente e lo stesso principio vale per l’uso dei sensori. L’implementazione di una soluzione deve essere il piùsemplice possibile, e non deve avere impatto sul tempo di startup di un’applicazione. Anche il sistema di gestione dei diritti delle applicazioni necessita di essere semplice e comprensibile. La soluzione adottata in Ubuntu si chiama AppArmor.

2.5.2 Introduzione ad AppArmor

AppArmor èun modulo di sicurezza del kernel Linux che implementa un MAC (Mandatory access control). Insieme al tradizionale sistema Unix dei permessi utente, permette di limitare le App a un limitato set di risorse. AppArmor èuna tecnologia giàmatura, utilizzabile per confinare applicazioni su ogni installazione default Ubuntu a partire dalla versione 7.10 (Ubuntu Gutsy Gibbon). Il livello di confinamento che AppArmor adotta su ogni applicazione èdefinito da profili associati alle applicazioni e memorizzati all’interno del kernel. Se un profilo non viene specificato per un particolare binario, tale binario non saràconfinato. In tal caso, tuttavia, saranno sempre valide le restrizioni imposte del tradizionale sistema dei permessi utente Unix. Nel caso di un programma in esecuzione sotto un determinato profilo AppArmor, qualora questo dovesse ten- tare l’accesso ad un percorso non autorizzato, AppArmor impediràtale accesso e il programma potrebbe andare in crash. Focalizzandoci maggiormente su AppArmor, il diagramma di Figura7 rappresenta il suo funzionamento.

Figura 7: Architettura AppArmor 15.

Nella parte inferiore della ﬁgura si trova il kernel. Il LSM (Linux Security Module, [24]) `e un 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 possibilità di operare a livello kernel pur non facendone propriamente parte. Ciòconsente di conservare all’interno di AppArmor le policy di sicurezza per ogni applicazione, evitando di dover applicare patch al kernel tutte le volte che si ha il bisogno di modificarle. Fondamentalmente, LSM chiede ad AppArmor se le operazioni che un’applicazione vuole eseguire possono essere concesse. Nella parte superiore dell’immagine si trova l’AppArmor management software (nello schema semplicemente AppArmor), che rappresenta l’insieme di tool per modificare manualmente le policy. In arancione sono rappresentate le applicazioni, ognuna delle quali potràavere un’AppArmor policy corrispondente che ne descrive i permessi. Secondo i progettisti di AppArmor, portare la sicurezza a livello kernel, come permesso dal- l’interfaccia LSM, èdi importanza fondamentale ai fini di garantire la sicurezza. Come Crispin Cowan, direttore del Software Engineering Security Architect, ha detto, la sicurezza fatta a livello di libreria èsolo apparente, sembra che le applicazioni non possano fare quel che gli è vietato, ma l’attaccante che riesce a infettare l’applicazione puòbypassare la libreria e arrivare al kernel. Questo, invece, non èil caso della sicurezza a livello di kernel [25]. E` risaputo che, di norma, una lista di permessi puòessere espressa secondo un modello black list (in cui tutto èconcesso a parte quanto espressamente vietato) oppure white list (in cui tutto èvietato tranne quanto espressamente concesso). Il secondo èindubbiamente un modello più sicuro, ma piùdifficile da mantenere perchéper funzionare bene richiede che nessun permesso di quelli necessari sia omesso. Quello di AppArmor èuna sorta di modello ibrido: a livello di applicazione usa una white list, perchéspecifica i percorsi a cui essa puòaccedere, quando tutti gli altri sono vietati. A livello di sistema èinvece una black list, perchésolo le applicazioni con una policy definita saranno ristrette. Quando un eseguibile viene lanciato, il kernel esamina il suo percorso e cerca se esiste una policy definita da applicare per tale applicazione. Se non la trova, l’applicazione saràavviata non confinata. Tramite la aa-exec utility èpossibile eseguire un certo programma sotto un determinato profilo AppArmor, specificato a parte, e tramite l’API aa change profile si puòcambiare profilo a un programma durante l’esecuzione. AppArmor si occupa inoltre di far ereditare le policy del parente ai nuovi eseguibili lanciati a runtime.

2.5.3 AppArmor proﬁle

Si tratta di un file di testo contenente le regole che descrivono le risorse a cui un’applicazione puòaccedere. In particolare puòspecificare:

• Controllo di accesso sui singoli percorsi;

• Controllo di accesso a funzionalit`adi sistema [26];

• Controllo di accesso a D-Bus;

Si mostra di seguito un esempio di proﬁlo AppArmor: #i n c l u d e capability sys time , capability sys chroot , dbus ( send )

25 bus=session path=/org/freedesktop/DBus interface=org. freedesktop .DBus member=Hello peer=(name=org . freedesktop .DBus) , deny signal (send) set=(int),

/etc/ntp.conf r, /etc/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 èconcesso l’accesso. Una lista delle capabilitie supportate èdisponibile in [26]. • Successivamente si trova la dichiarazione di un permesso di tipo D-Bus. D-Bus èil meccanismo utilizzato in Ubuntu e molti altri sistemi POSIX per l’IPC (Inter Process Communication). • La keyword signal èutilizzata a partire da Ubuntu 14.04 LTS per specificare quali segnali un’applicazione puòinviare e/o ricevere. Nel caso visto sopra, si vieta all’applicazione di inviare segnali di interruzione ad altri processi. • Infine si ha la dichiarazione dei percorsi consentiti con i relativi permessi di lettura/- scrittura/esecuzione. Si noti come quest’ultima possa essere semplificata attraverso l’uso di regular expressions.

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

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

2.5.4 Policy Groups

Specificare il profilo AppArmor direttamente all’interno del package dell’applicazione rappre- senterebbe una grande complicazione nella mani dello sviluppatore, non in linea con la filosofia volta alla semplificazione discussa precedentemente. Inoltre, permettere agli sviluppatori di scrivere manualmente il profilo AppArmor per le applicazioni destinate allo store online, renderebbe difficile la revisione automatica delle applicazioni. Tale processo si basa, infatti, sui

26 permessi concessi all’App. I Policy Groups rappresentano la soluzione a questo problema. Il profilo AppArmor non viene scritto manualmente dagli sviluppatori, bens`ıgenerato automaticamente al momento dell’installazione sulla base di direttive di piùalto livello (Policy Groups) definite all’interno del Click package. Si vuole vedere nel dettaglio come funziona. All’interno di un file manifest, contenuto nel Click package di un’applicazione, sono specificati i Policy Groups che tale applicazione richiede. Esempi di Policy Groups sono:

• camera: accesso alla fotocamera;

• content exchange.: permesso di condividere contenuto;

• location: accesso ai servizi di localizzazione;

• contacts: accesso alla lista dei contatti;

• gallery: accesso alla galleria immagini;

• networking: permesso di comunicare tramite le interfacce di rete.

Insieme a specifici Policy Groups èpossibile indicare un template da cui partire, che rappresenta un insieme di regole AppArmor predefinito, adatto ad un particolare tipo di applicazione. Al momento i Policy Templates supportati sono:

• ubuntu-sdk: template di default, se nessun altro speciﬁcato.

• ubuntu-webapp: un template specializzato per l’utilizzo con la piattaforma Ubuntu Webapps.

• ubuntu-scope-network: template specializzato per gli scopes16 che richiedono accesso a internet. Di norma agli Scopes non `econcesso utilizzare la stessa gamma di Policy Groups concessa agli altri tipi di applicazione.

• unconfined: fornisce permessi massimi all’applicazione. Questo template èriservato ad applicazioni che sono specificamente fidate e non puòessere utilizzato da normali sviluppatori.

Di seguito si mostra un esempio di ﬁle manifest.json. Il ﬁle contiene un oggetto “Hooks” che trasporta le informazioni di nostro interesse. Potrebbe apparire ad esempio in questo modo: { [...] hooks : { myApp: { apparmor: myApp.json , content−hub : myAppCH. json } [...] } } [...] }

16In Ubuntu Touch, uno scope `euna sorta di widget posizionabile nella schermata di home.

27 Ciòvuol dire che il file myApp.json contiene sia le informazioni relative ad AppArmor, sia quelle specifiche per il content-hub (vedremo in seguito di cosa si tratta). Il file myApp.json potrebbe avere un contenuto come il seguente, in cui comunica che si vuole poter accedere alla videocamera, al GPS e al microfono. { 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 Figura 8, ognuno dei possibili Policy Groups rappresenta diverse entry nel formato AppArmor. E` importante notare che, come saràillustrato in 2.5.5, specificare ad esempio camera nei policy groups, non significa che, una volta installata, l’applicazione avràil permesso di accedere alla fotocamera: serviràun ulteriore consenso dell’utente, fornito attraverso i cosiddetti Truster Helpers.

Figura 8: Scelta Policy Groups 17

La lista di Policy Groups svolge, inoltre, il ruolo di semplificare il processo di revisione di un’applicazione. Lo store legge automaticamente il contenuto del file manifest e ne estrae i permessi richiesti. Qualora fossero richiesti Policy Groups non considerati pericolosi, l’applicazione sarebbe immediatamente accettata. In caso contrario, potrebbe subire un processo piùlungo di revisione manuale.

2.5.5 Gestione autorizzazioni: Trusted Helpers

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

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

28 servizi che gestiscono dei dati o sensori, non èperòsufficiente a consentire all’App l’accesso a questi ultimi. Serve esplicita autorizzazione dell’utente, si mostra ora come. Nel modello di sicurezza adottato, gli utenti prendono decisioni riguardo la concessione di operazioni sensibili nell’esatto momento in cui esse sono richieste. Ciòèottenuto attraverso l’uso di componenti che prendono il nome di Trusted Helpers. In generale, gli helpers sono processi che gestiscono l’accesso di una applicazione a dei servizi esterni: ad esempio, esiste l’helper della fotocamera, con cui un’applicazione deve comunicare se vuole scattare foto. Esistono anche helper per il calendario, i contatti ecc... La comunicazione con tali helper avviene attreverso D-Bus, dunque, poichèle comunicazioni tramite D-Bus sono controllate da AppArmor, il profilo di sicurezza di un’applicazione potrebbe vietare la comunicazione con certi helpers. Qualora invece il profilo AppArmor concedesse tale comunicazione, l’helper potrebbe gestire l’accesso alla risorsa di sua competenza visualizzando un messaggio di conferma all’utente. In tal caso prende il nome di Trusted Helper. I Trusted Helpers rappresentano dunque il punto in cui l’utente puòprendere la decisione di concedere o negare un certo privilegio, indipendentemente da quanto scritto sul profilo AppArmor. Infatti, il contenuto del profilo AppArmor non è visualizzato all’utente, e dipende solo da quanto dichiarato nel file di manifest dell’applicazione, compilato dallo sviluppatore. Questo modello fa si che i privilegi richiesti all’interno del file di manifest rappresentino solo ciòdi cui l’applicazione potrebbe aver bisogno, ma accettare di installare un’applicazione che richiede l’accesso alla fotocamera non vuol dire, come nel modello Android, giàconsentire tale accesso, ma significa concedere alla App di richiedere al Trusted Helper della fotocamera di utilizzare tale servizio. I Trusted Helpers possono anche svolgere funzioni piùcomplesse che gestire un accesso “booleano” di una App. Un esempio èquello degli Online Accounts: la AppArmor policy “online accounts” specifica se una App puòcomunicare o meno con l’helper degli Online Accounts, ma tale helper dovràgestire al suo interno la scelta dell’account specifico a cui fornire accesso. Ciòsaràfatto attraverso opportuni messaggi di richiesta (ad esempio “Vuoi consentire all’applicazione X di accedere all’account Y?”). Online Accounts puòmemorizzare in cache la risposta. Come si puòintuire, questo sistema mischia le policy di AppArmor con quelle dei Trusted Helpers. Infatti, Online Accounts agli occhi dell’utente ècome se stesse modificando le policy di sicurezza quando salva la scelta di un utente, sebbene il profilo AppArmor resti sempre invariato. In questo modo èpossibile dalle impostazioni modificare in un secondo momento i permessi concessi ad una applicazione. Ad esempio saràpossibile revocare l’accesso ai contatti. Secondo la documentazione, questo modello su due livelli (AppArmor e Trusted Helpers) potrebbe essere rivisto in futuro a favore di uno unico, in modo che sia piùordinato e gestibile [28].

2.5.6 Condivisione contenuti: Content Hub

Nonostante le applicazioni siano confinate, esse spesso hanno bisogno di scambiare dati con altre applicazioni. Si èvisto come i Trusted Helpers possano mediare l’accesso a servizi quali fotocamera e GPS, ma come funziona il trasferimento sicuro di file come immagini e musica tra applicazioni? Come puòuna App essere esportatrice o importatrice di un certo tipo di file? Il meccanismo sviluppato per risolvere questi problemi si chiama Content Hub. Il suo scopo è quello di fornire una API e un servizio runtime che dia alle App la possibilitàdi condividere e importare contenuto da altre applicazioni. Al momento, lo sviluppo del Content Hub non è ancora terminato, tuttavia se ne discutono qui le principali caratteristiche. Content Hub si basa su alcuni principi chiave:

29 • Il contenuto `eproprietario: ogni pezzo di contenuto `eposseduto da una e una sola applicazione. Non esiste un’applicazione che possiede, ad esempio, tutte le immagini.

• Ciascun contenuto ha una App di default: per esempio, l’applicazione predeﬁnita per le immagini `ela Gallery.

• Le applicazioni possono registrarsi come sorgente per un certo tipo di contenuto: questo permette al sistema di mostrare una lista di App sorgenti da cui lo user possa scegliere nel caso voglia importare un ﬁle. Oppure, un’App che sta importando pu`onominare una applicazione sorgente.

• Le applicazioni possono registrarsi come destinazione per un certo tipo di contenuto: il sistema pu`oallora mostrare le applicazioni che possono ricevere questo tipo di contenuto. Ad esempio, l’utente potrebbe voler salvare un’immagine dal web browser, il sistema gli presenta una lista di applicazioni tra cui pu`oscegliere dove salvarla.

• Content transfer object: `el’oggetto che rappresenta un trasferimento. Ha una applicazione sorgente, una destinazione, del contenuto e uno stato. Una applicazione sorgente carica il contenuto che vuole esportare all’interno di questo oggetto; quando ha terminato, imposta il transfer state a charged, e il trasferimento pu`ocominciare.

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

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

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

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

3. Il Content Hub lancia il selector GUI della App sorgente per la selezione delle immagini da parte dell’utente. A quel punto il transfer object viene caricato con le immagini selezionate e segnato come pronto. Inﬁne la galleria viene chiusa.

4. La nostra applicazione in ricezione vede che il transfer object `epronto (dal suo stato) ed `epronta ad importare l’immagine.

5. La nostra applicazione pu`outilizzare l’immagine e salvarla in modo permanente utilizzando una apposita API (“contentStore”).

Come si `evisto, il Content Hub, tramite il trasfer object, fa da intermezzo tra le due applicazioni. L’utilizzo di un’interfaccia appartenente all’applicazione sorgente per la selezione delle immagini, garantisce che l’applicazione di destinazione non acceda in alcun modo al contenu- to non desiderato dall’utente. Questo sistema consente inoltre di non dover fornire l’accesso completo a tutte le immagini, ma solo a quelle desiderate. Figura9 mostra un confronto tra i sistemi 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 èconfinata e puòscambiare contenuto con le altre App tramite Content Hub.

2. Windows: le applicazioni non sono conﬁnate e possono accedere ognuna al contenuto dell’altra.

3. iOS: simile a Content Hub, ma invece di un singolo Hub esistono dei “Content Pools” che trattano contenuti speciﬁci. Ad esempio il Music Content Pool. Le applicazioni condividono contenuti tramite questi “pools”.

Registrazione di una App come sorgente o destinazione Come detto, le App che espor- tano contenuto (App sorgenti) hanno bisogno di registrarsi come sorgenti per quel determinato tipo di contenuto. Allo stesso modo, le App si possono registrare per poter essere destinatarie di un certo tipo di contenuto. Questa registrazione consiste nel renderlo noto al Content Hub. La registrazione avviene attraverso le informazioni inserite nel ﬁle di manifest. Rifacendosi all’esempio della sezione 2.5.4, il ﬁle myAppCG.json potrebbe contenere il seguente contenuto per 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 ﬁnale. Nell’interesse di analizzare particolarmente la sicurezza di Ubuntu Touch, ci si concentra sul caso dei ClickPackages, scaricabili dall’App store, e considerati untrusted secondo il modello adottato.

2.6.1 Creazione e ﬁrma digitale delle applicazioni

Lo sviluppo di un modello pi`uveloce di App store, di cui si `eparlato nella sezione 2.3.4, ha portato con se anche l’adozione di un nuovo sistema di impacchettamento delle applicazioni,

31 denominato ClickPackages. I ClickPackages sono semplici pacchetti di installazione, la cui procedura di creazione ènotevolmente semplificata attraverso l’uso dell’Ubuntu SDK. Tramite l’Ubuntu SDK èpossibile, al momento della creazione del pacchetto, specificare i Policy Groups, in modo tale da automatizzare la creazione del file manifest associato. Dettagli del file manifest restano comunque modificabili manualmente. Dopo aver creato il pacchetto, lo sviluppatore puòfirmarne il contenuto utilizzando una propria chiave privata. Tale chiave, insieme alla sua corrispondente chiave pubblica, puòessere generata tramite l’Ubuntu SDK. Per la firma si utilizza il tool debsign tra le cui opzioni èpossibile speicifcare che la firma èdi tipo maint, ovvero si tratta della firma di chi si occupa del mantenimento del pacchetto. Nel caso in cui lo sviluppatore desideri firmare il pacchetto con la propria chiave privata, ènecessario che egli pubblichi sul portale Online di Ubuntu, nella sezione relativa al proprio profilo (accessibile tramite apposite credenziali), la corrispondente chiave pubblica. Dunque, possiamo dire che, di fatto, la firma garantisce che lo sviluppatore del pacchetto in questione sia il possessore di tali credenziali, ma non da alcuna garanzia sulla persona fisica che sta dietro ad esse.

2.6.2 Upload, controllo e ﬁrma digitale dello store

Una volta preparato il Click package, eventualmente firmato, si procede al caricamento tramite un’apposita pagina web (https://myapps.developer.ubuntu.com) sul portale MyApps, dove allo sviluppatore èrichiesto di autenticarsi tramite username e password. A caricamento completato, se il pacchetto era firmato, MyApps verifica che la firma dello sviluppatore sia valida. Successivamente lo store esegue i controlli di sicurezza. Se i Policy Groups utilizzati non sono considerati pericolosi, la App èautomaticamente approvata. Altrimenti puòessere soggetta a un controllo manuale, in cui alcuni tecnici possono ispezionare il codice sorgente. Ad applicazione approvata, lo store firma automaticamente a sua volta il pacchetto utilizzando sempre debsign e la propria chiave privata. Questa viene specificato che la firma èdi tipo origin, ovvero dell’entitàche si occupa della distribuzione del pacchetto agli utenti. Infine, lo store genera e memorizza lo SHA-512 del pacchetto finale firmato [31].

2.6.3 Download e veriﬁca della ﬁrma digitale

Nel momento in cui un device cerca informazioni su un pacchetto, riceve dallo store dei metadati che contengono i seguenti campi: un download url che contiene l’url da cui scaricare il click package, e il download sha512 che contiene lo SHA-512 del click package, precalcolato dallo store. Quest’ultimo sar`autilizzato dal servizio di download eseguito sul dispositivo per validare l’integrit`adel pacchetto ricevuto. Si mostra il procedimento nel dettaglio:

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

• ClickScope chiede al DownloadManager di iniziare il download.

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

• Il download manager chiede all’install helper di iniziare l’installazione, passandogli il ﬁle appena scaricato. La comunicazione con l’install helper avviene tramite D-Bus ed `e mediata da AppArmor.

19ClickScope `eil modulo dedicato alla ricerca di nuovi pacchetti installabili

32 • L’install helper chiede a Package Kit di installare il Click package. • Package kit veriﬁca la ﬁrma dello store e porta a termine l’installazione.

Come detto nella sezione 2.5.4, nel corso dell’installazione saràcreato e memorizzato il profilo AppArmor corrispondente ai Policy Groups dichiarati. Al momento si sta valutando se (e come) concedere in futuro di poter accettare pacchetti firmati solo dallo sviluppatore e non dallo store [31].

2.7 Memorizzazione dati critici

2.7.1 GNOME Keyring e AppArmor

Oggi si sta ancora valutando come integrare GNOME Keyring, discusso in appendice, con il sistema di confinamento di AppArmor. Al momento per default èvietato l’accesso diretto a questo servizio da parte delle App confinate. Possono invece accedervi altri servizi come Online Accounts. Si pensa che, in futuro, se un’App necessiteràdell’uso di Keyring, tale accesso sarà mediato da Apparmor: quando un’applicazione vorràrecuperare delle credenziali, se il profilo AppArmor glielo consentirà,saràconcesso l’accesso solo alla credenziali salvate da quella stessa applicazione. Si sta valutando anche se estendere l’integrazione di AppArmor al fine di rendere possibile l’accesso a credenziali che appartengono ad altre applicazioni, permettendolo o direttamente nell’AppArmor profile oppure visualizzando all’utente una richiesta di autorizzazione [32].

2.7.2 Credenziali web: Ubuntu online accounts

E` un luogo centralizzato per memorizzare le credenziali degli account web. Ogni applicazione avviata dall’utente puòaccedere al database file degli account. Ubuntu Online Accounts è accessibile tramite D-Bus. L’accesso alle credenziali che esso contiene èprotetto, come per altri servizi, su due livelli distinti (vedi sezione 2.5.5). Un booleano specificato in AppArmor specifica se tale applicazione puòin generale accedere al servizio Ubuntu Online Accounts. Successivamente ècompito di quest’ultimo di gestire i permessi sul singolo account (ovvero a quali degli account memorizzati una certa applicazione puòaccedere), e, in caso di necessità,è visualizzato a runtime un avviso che chiede se concedere o meno l’autorizzazione [32].

2.8 Cifratura dati utente

2.8.1 Introduzione a eCryptfs

La cifratura dei dati utente rappresenta una protezione principalmente contro gli attacchi offline. In particolare èin grado di proteggere la segretezza dei dati nel caso in cui il dispositivo mobile fosse rubato o in generale si riuscisse a scavalcare le protezioni a livello del sistema operativo. Si noti che, al contrario, le tecniche di isolamento delle applicazioni discusse precedentemente sono protezioni a livello software, il quale progettato in modo da vietare l’accesso non autorizzato a dati che peròsono fisicamente memorizzati in chiaro. Cifrando i dati si ha invece protezione a livello fisico, nel senso che abbiamo la “certezza” che se anche un utente malevolo riuscisse ad avere accesso fisico all’hard disk (ad esempio connettendolo ad un altro computer o più semplicemente eseguendo il boot con un altro sistema operativo) non sarebbe in grado di decifrarne il contenuto, senza conoscere il segreto che lo protegge.

33 Al momento, le opzioni di cifratura dei dati utente possibili su Ubuntu Desktop, non sono replicate nella versione Touch. Ubuntu sta pianificando di portare queste soluzioni anche sui dispositivi mobili. Gli sviluppatori hanno confermato che questa funzionalitàsaràimplementata utilizzando il file system crittografico eCryptf, nello stesso modo in cui esso èutilizzato in Ubuntu Desktop. Si tratta di un file system crittografico “stacked”. Il termine stacked indica che esso si dispone al di sopra del file system giàpresente, indipendentemente da quale esso sia, e ne protegge i file cifrandone il contenuto e inserendo metadati crittografici nei rispettivi header. Questa soluzione a livello di file system consente ai file protetti di essere maneggiati normalmente, copiati tra diversi host e decriptati solo in un secondo momento. Lo svantaggio risiede nel fatto che, sebbene il contenuto dei file sia cifrato, la struttura del file system sia sempre in chiaro. La soluzione complementare alla crittografia a livello di file system (file system level encryption) èla full disk encryption, non disponibile in Ubuntu Touch, che cifra l’intero file system ma, oltre ad essere computazionalmente piùdispendiosa, non consente i vantaggi suddetti. Vantaggio della full disk encryption èche, cifrando l’intero disco, protegge anche lo spazio di swap20, lasciato invece sempre in chiaro da eCryptfs. Questo avviene perché,per questioni di ottimizzazione, lo spazio di swap viene gestito con un particolare file system dedicato gestito direttamente dal kernel. Il rischio maggiore si corre nel caso in cui il dispositivo fosse lasciato in ibernazione: in tale circostanza, il contenuto della RAM, prima che il dispositivo si spenga, ècopiato nello spazio di swap e eCryptfs non ha modo di proteggerlo.

2.8.2 Funzionamento di eCryptfs

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

20Lo spazio di swap èuna porzione di hard disk che funge da RAM virtuale, ed èutilizzato quando la memoria non èsufficiente a soddisfare le richieste dei processi in esecuzione. 21Sorgente immagine: [33].

34 Si illustra ora il funzionamento di eCryptfs, con riferimento alla Figura 10. Il sistema di gestione delle chiavi utilizzato in eCryptfs si ispira alle specifiche OpenPGP (RFC 2440). Ciòinclude la procedura di utilizzare una gerarchia di chiavi nell’eseguire operazioni crittografiche. Il contenuto di ogni file da proteggere èdiviso in blocchi da 128 bit e cifrato con AES-128- CBC tramite le Crypto API del kernel Linux. La chiave di cifratura prende il nome di File Encryption Key (FEC), ed ègenerata in modo casuale al momento della creazione del file. La FEC viene poi a sua volta cifrata con un’altra chiave, detta File Encryption Key Encryption Key (FEKEK), per ottenere la Encrypted File Encryption Key (EFEK). La EFEK viene infine memorizzata all’interno dell’header del file in questione. Resta da capire l’origine della FEKEK. Tale chiave nei dispositivi desktop èottenuta direttamente dalla password di login. Nel caso di device mobile, possiamo pensare al login come allo sblocco del device22. Al momento del login, alla password utilizzata viene aggiunto del sale e applicata ricorsivamente una funzione di hash (generalmente HMAC-SHA-512), il cui risultato èla FEKEK. A questo punto la FEKEK viene memorizzata nel kernel keyring fino al logout dell’utente23. Ciòpermette di evitare di eseguire piùvolte nel corso della stessa sessione l’algoritmo di hashing suddetto, il quale èvolutamente “lento” (1000 o piùiterazioni) al fine di contrastare attacchi di tipo brute-force. Si mostra ora come avviene l’accesso ad un file protetto da eCryptfs. Le applicazioni, eseguite nello userspace, fanno richieste di accesso a files tramite system calls al Virtual File System (VFS) del kernel. Sia eCryptfs, sia il file system a esso sottostante (ad esempio ext3, JFS, NFS ecc...) sono registrati nel VFS. Nel momento in cui èrichiesto l’accesso a un file cifrato, eCryptfs recupera nel keyring del kernel la FEKEK, memorizzatavi al login. Questa chiave viene utilizzata per decifrare la EFEK letta dall’header del file richiesto. La FEK cos`ıottenuta viene memorizzata nei metadati di eCryptfs relativi al file in questione e utilizzata per decifrare il contenuto del file [34][35][33].

2.9 Protezione dell’accesso

Come ogni sistema operativo mobile, insieme alle protezioni di basso livello viste precedentemente, Ubuntu Touch offre la possibilitàdi proteggersi dal furto di dati bloccando il dispositivo con una password alfanumerica da 5 caratteri. La password non viene memorizzata in chiaro bens`ı viene aggiunto del “sale” e il suo hash con MD5 èsalvato in /etc/shadow. Per maggior sicurezza, sono eseguite 5000 iterazioni della funzione di hash. L’aggiunta di sale èutile ad esempio per difendersi contro attacchi di tipo dizionario. Il formato di salvataggio prevede una stringa con 3 campi separati dal carattere dollaro, ad esempio $1$jQdk4iTA$lanDFksSowpaElsSD, dove i campi sono:

• algoritmo di hash utilizzato (1 signiﬁca MD5)

• sale aggiunto alla password

• hash di password + sale

Secondo le nostre fonti, e a quanto risulta dal test sull’emulatore, non sembrano esistere altri sistemi di protezione.

22Al momento non si hanno dettagli a come questo saràgestito. E` anche possibile che saràconsiderato come login solo il primo accesso dopo l’avvio del dispositivo. 23Anche qui, potràessere lo sblocco o lo spegnimento del dispositivo.

35 2.10 Altri elementi di sicurezza

2.10.1 GSettings/dconf

GSettings èuno strumento per memorizzare le impostazioni di configurazione delle applicazioni. Sfrutta dconf come back end plugin, con cui i processi comunicano tramite D-Bus per leggere e scrivere le impostazioni dal e sul database. Le applicazioni non confinate possono leggere e modificare impostazioni per le altre applicazioni. Ciòpotrebbe voler dire, ad esempio, aggiungere plugin arbitrari che siano eseguiti al caricamento di un’altra applicazione. Anche solo avere l’accesso in lettura alle impostazioni delle altre applicazioni puòesporre informazioni sensibili e causare problemi di privacy. Dalla versione 13.10 le App confinate non hanno accesso a GSettings. Nonostante si potrebbe utilizzare una protezione di tipo booleano per l’accesso, specificata tramite AppArmor, secondo gli sviluppatori non si avrebbe abbastanza sicurezza. In futuro, si legge nella documentazione, si potràpermettere alle applicazioni confinate di salvare le loro informazioni in GSettings, ma ciòrichiederàuna modifica di dconf, in modo tale che sia in grado di tener conto di quali impostazioni un’applicazione puòandare a leggere. La mediazione di AppArmor sul D-Bus medieràla comunicazione tra le applicazioni confinate e il demone dconf.

2.10.2 Display manager

Come descritto in 2.3.2, Ubuntu usa il server graﬁco Mir. Si elencano alcuni dei problemi di sicurezza che Mir, con l’aiuto delle policy di AppArmor, ha risolto rispetto al precedente X Server.

• Keyboard and mouse sniﬃng: alle applicazioni eseguite sullo stesso X server era concesso eseguire operazioni di sniﬃng dei tasti premuti e eventi del mouse. Questo poteva permettere ad una applicazione di catturare i dati inseriti in altre applicazioni.

• Screenshot: in X ogni applicazione poteva scattare screenshot anche quando in background. Ci`opermetterebbe alle applicazioni di catturare dati sensibili mostrati in altre applicazioni. La progettazione di Mir previene queste azioni (una normale applicazione pu`osolo fare lo screenshot del proprio contenuto).

• XSettings: il protocollo XSettings fornisce un meccanismo per far condividere a diverse applicazioni le stesse impostazioni di interfaccia quali il timeout per il doppio click e i colori di interfaccia. Il Settings Manager usato in X mantiene una finestra unmapped (unica per tutti i processi) dove sono memorizzate tutte le impostazioni. Esistono toolkits, come GTK, che permettono il caricamento di moduli arbitrari specificati tramite XSettings. Ciòpuòinfrangere i confini dell’applicazione.

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

36 user-facing24. Mir non supporta XSettings a livello di applicazione. In altre parole `epossibile accedere alle impostazioni tramite la shell, mentre le applicazioni non possono accedervi, modiﬁcarle, o impostare il caricamento di moduli esterni.

2.10.3 Environment variables

Molte librerie consentono di avere comportamento diverso impostando alcune variabili d’ambiente prima di essere avviate. Ad esempio, GTK25 permette di specificare moduli arbitrari da essere caricati impostando la variabile di ambiente GTK MODULES. Per questo motivo, sarebbe meglio che le variabili d’ambiente fossero ispezionate prima dell’avvio di processi che devono essere eseguiti confinati, in quanto ciòpotrebbe essere utilizzato per violare i confini. La soluzione adottata consiste nel cosiddetto Environment scrubbing, ovvero la rimozione di varie variabili d’ambiente considerate pericolose prima dell’avvio di un eseguibile confinato [36] [32].

2.10.4 Segnali tra processi

Nelle versioni precedenti a Ubuntu 14.04 LTS ogni applicazione poteva inviare un segnale ad ogni altra applicazione in esecuzione, come il segnale TERM che causa la terminazione di un processo. Attualmente, come visto nell’esempio in 2.5.3, il profilo AppArmor deve poter specificare quali segnali un’applicazione confinata puòinviare agli altri processi.

2.10.5 Protezione da remoto

A differenza di Android e iOS, Ubuntu Touch non ha a disposizione un sistema di protezione da remoto built-in che consenta di bloccare il dispositivo, localizzarlo o cancellarne i dati. Attualmente èpossibile avere questa funzionalitàcon applicazioni di terze parti come Prey [37]. Tuttavia, l’efficacia di una soluzione basata solo su software èmolto discutibile nel nostro caso. E` vero che il sistema puòsupportare applicazioni preinstallate che non possono essere rimosse dall’utente, tuttavia, se si collega il dispositivo a un computer via USB e si utilizzano gli strumenti di sviluppo di Android, il device puòad ogni modo essere totalmente resettato. Al momento, dunque, sembra non esserci soluzione lato sistema operativo. Ogni tipo di supporto anti ladro deve essere implementato a basso livello dai produttori dell’hardware.

2.10.6 Certiﬁcati

Ubuntu Touch memorizza i certificati all’interno di file situati nella cartella /usr/share/ca- certificates. L’estensione di questi file è.crt, e il formati dei certificati èPEM. Per ragioni di sicurezza, a differenza della versione desktop, questa cartella èdi sola lettura, dunque non è possibile installare manualmente certificati auto firmati.

24Processi non al momento visualizzati a schermo 25GTK+, detto anche GIMP Toolkit, `eun toolkit multi piattaforma per la creazione di interfacce utente graﬁche.

37 2.11 Vulnerabilit`anote

Per Ubuntu Touch si utilizza lo stesso database di CVE utilizzato per Ubuntu. Tale database mostra le diverse vulnerabilitànote, specificandone i livelli di criticitàe il package corrispondente. E` inoltre possibile visualizzare come il livello di criticitàsia differente nelle diverse versioni di Ubuntu. Il database è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 stile Ubuntu, si èvisto come in realtàUbuntu Touch nasconda una grande innovazione. L’intento di realizzare una soluzione software congiunta in grado di adattarsi contemporaneamente a smartphone, tablet e desktop ha portato con se la necessitàdi sviluppare un modello di sicurezza adatto a tale contesto. Con piùdi 15 anni di storia alle spalle, AppArmor rappresenta uno strumento che ha maturato l’esperienza necessaria per farsi carico di buona parte di questo difficile compito. Si èvisto come il suo funzionamento si basi sulla prevenzione, e non richieda un continuo processo di scanning del sistema che minerebbe l’autonomia del dispositivo. La definizione del confinamento di un’applicazione, giàpiùsemplice in AppArmor rispetto a altre soluzioni quali SeLinux, èstata ulteriormente semplificata con i Policy Groups. Affiancan- do a ciòun potente SDK, si èriusciti a rendere questo strumento immediatamente accessibile ai nuovi sviluppatori. Dal punto di vista dell’utente, i Trusted Helpers forniscono, tramite messaggi di avviso come Consentire all’applicazione di accedere alla fotocamera?, massima trasparenza sui permessi concessi a un’applicazione. Essi permettono inoltre di revocare le autorizzazioni in un secondo momento, opzione non presente in un diffuso sistema come Android. Il sistema semi automatizzato di revisione delle nuove App consente tempi brevissimi di pubblicazione di nuovo software e puòessere utile per portare sui device aggiornamenti di sicurezza delle applicazioni in breve termine. Per essere approvate in automatico, le App devono ri- specchiare requisiti di sicurezza molto restrittivi che ne assicurano l’innocuitànei confronti del sistema: nel caso peggiore, il confinamento garantisce che i danni di un attacco siano limitati al campo di azione della App stessa. Condividendo con Ubuntu Desktop l’architettura generale, il sistema puòbeneficiare dei suoi aggiornamenti di sicurezza. Infine, trattandosi di un sistema open source, vanta la possibilitàdi beneficiare del contributo di una vastissima community, importante mezzo per la scoperta e correzione di falle di sicurezza. Si conclude l’analisi con alcune osservazioni critiche.

• In quanto nuovo sistema operativo in un mercato governato dai colossi Android e iOS, uno degli obiettivi primari dello sviluppo di Ubuntu Touch èincentivare lo sviluppo di applicazioni, e il modo migliore per riuscirci èrenderlo il piùsemplice possibile. Questo giustifica l’uso dei Policy Groups nei Click packages. Tuttavia, non poter specificare manualmente un profilo AppArmor per i Click package potrebbe essere in futuro una limitazione. Al momento, infatti, tutti i permessi AppArmor richiesti da un’applicazione devono avere un corrispondente in un Policy Group. Tale modello potrebbe collassare di fronte alla

38 necessitàdi avere un modello di sicurezza piùcomplesso che permetta di definire il confinamento con piùdettaglio. Naturalmente, si perderebbe il vantaggio di una revisione automatica dell’applicazione da parte dello store. Per questo, una soluzione potrebbe essere concedere la possibilitàallo sviluppatore di definire profili AppArmor manuali per i propri Click package a patto che essi siano revisionati manualmente, eventualmente sotto pagamento di una commissione.

• Al momento il confinamento delle applicazioni èfatto su due livelli: AppArmor e Trusted Helper. Nel momento in cui un Trusted Helper memorizza un certo permesso concesso dall’utente, l’applicazione in questione puòaccedere (da l`ıin avanti) a una determinata risorsa prima proibita. In tutto ciò,il profilo AppArmor èrimasto invariato. Esso semplicemente dichiara la possibilitàper quell’applicazione di comunicare con lo specifico Trusted Helper, ma non contiene informazioni riguardo la scelta dell’utente. Questo meccanismo fa si che il profilo AppArmor non sia sufficiente per determinare i privilegi di un’applicazione. Sarebbe meglio che tali informazioni fossero concentrate in un unico punto. Ad esempio si potrebbe estendere AppArmor al fine di memorizzare in un profilo anche le definitive autorizzazioni concesse dell’utente. In tal caso dovrebbe essere capace di modificare dinamicamente il profilo in funzione di esse.

• Al fine di non impattare l’autonomia del dispositivo, non èpresente un sistema di monitoring costante delle risorse utilizzate dai processi. Inoltre, condividendo l’architettura con Ubuntu desktop, non si ha ancora un sistema di gestione ottimizzata dei processi in background: in altre parole, come su Ubuntu Desktop, èconcessa l’esecuzione in background senza limitazione di risorse. In questo modo un’applicazione intenzionata a saturare le risorse del dispositivo in termini di CPU o a scaricare la batteria, potrebbe superare automaticamente i controlli di sicurezza dello store e portare a termine il suo scopo.

39 3 CyanogenMod

Figura 11: Schermata di home di CyanogenMod 26.

3.1 Modalit`adell’analisi di sicurezza

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

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” negli Stati 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. Avere l’accesso root, combinato alla natura open source del sistema operativo Android, ha permesso al firmware originale del telefono di essere modificato e re-installato sul telefono stesso. Ne- gli anni successivi molti firmware modificati furono sviluppati e distribuiti da appassionati di Android. Uno, mantenuto da uno sviluppatore chiamato JesusFreke, presto diventòpopolare tra i possessori del Dream. Nell’agosto 2009 JesusFreke smise di lavorare al suo firmware e sugger`ıagli utenti di passare a una versione della sua ROM che era stata ulteriormente miglio- rata dallo sviluppatore Cyanogen (Steve Kondik), chiamata “CyanogenMod”. La popolarità di CyanogenMod crebbe rapidamente e una piccola comunitàdi sviluppatori, conosciuta come CyanogenMod Team, contribu`ıal progetto. Nel giro di pochi mesi il numero di dispositivi e di funzionalitàsupportate da CyanogenMod aumentòe CyanogenMod diventòin poco tempo una delle distribuzioni di firmware Android piùpopolari [38].

3.2.2 Diﬀerenze con Android

CyanogenMod offre caratteristiche e opzioni non disponibili nel firmware ufficiale distribuito dai vendor di questi devices, come nuovi temi grafici, il supporto per codec audio FLAC27, CPU overclocking, gestione dei permessi delle app, un client OpenVPN, root access ed altri ancora. Se queste caratteristiche fanno pensare semplicemente a un sistema operativo che offre all’utente piùfunzioni e maggiore personalizzazione, si sottolinea anche che la progettazione di CyanogenMod èvolta a migliorare le performance, affidabilitàe sicurezza dei dispositivi. Come vedremo successivamente, queste caratteristiche positive portano con séun rovescio della medaglia. Fornire maggiori funzionalitàall’utente significa anche dargli maggiori permessi e, potremmo dire, maggior fiducia. Un utente inesperto potrebbe inconsciamente minare la sicurezza del proprio dispositivo, molto piùfacilmente che su sistemi più“chiusi” quali ad esempio iOS [39].

3.2.3 Distribuzione

Secondo le nostre informazioni, al momento CM èdistribuito come sistema operativo nativo solo sullo smartphone OnePlus One. Per gli altri dispositivi, èda intendersi come un sistema operativo installabile in sostituzione di quello giàpresente. Il 6 Gennaio 2015 èstata rilasciata l’ultima versione: CyanogenMod 12. Il firmware èrilasciato in diverse varianti: Stable, Release Candidate e Nightlies. La versione Stable, come lo stesso nome suggerisce, èquella maggiormente testata, conforme agli standard (informali) di sicurezza e stabilitàche la comunitàdegli sviluppatori si impone. Release Candidate èla fase subito precedente alla Stable: si tratta di una versione che non presenta bug o vulnerabilitàfatali, ma che non èancora stata testata completamente. Infine, le Nightlies sono piccoli aggiornamenti molto poco testati, rilasciati a distanza di poche ore l’uno dall’altro, e per questo motivo sconsigliati all’utente medio [40].

27Free Lossless Audio Codec `eun formato di codiﬁca audio che non comprime l’audio digitale.

41 3.2.4 Device Rooted

Il termine root indica il processo di acquisizione dei diritti di superuser all’interno di un sistema Linux o suo derivato, come Android. Il superuser possiede privilegi di amministratore, pertanto èin grado di accedere ad ogni dato all’interno del sistema e di eseguire operazioni potenzialmente pericolose per la stabilitàe sicurezza del sistema stesso. I sistemi Linux desktop permettono di ottenere privilegi di amministratore semplicemente attraverso la shell. La maggior parte dei sistemi operativi mobili Linux-based, essendo progettati per un’ampia utenza di competenza medio-bassa e facendosi carico delle problematiche di sicurezza trattate nell’introduzione di questo report, adottano invece una strategia piùrestrittiva, in cui all’utente sono fortemente limitate operazioni sensibili sul sistema. Il root (o rooting) viene spesse eseguito con lo scopo di superare queste limitazioni, imposte generalmente dagli operatori telefonici o dal produttore dell’hardware. Il rooting da l’abilità(o il permesso) di modificare o sostituire applicazioni preinstallate e impostazioni di sistema, avviare particolari applicazioni che richiedono permessi di amministratore, avere accesso di basso livello all’hardware, o eseguire altre operazioni che sono di norma inaccessibili a un normale utente Android [41]. Come ogni Mod che si rispetti, e al fine di rendere possibili molte delle caratteristiche vantag- giose che lo contraddistinguono dallo standard Android, CyanogenMod èin grado di fornire all’utente e alle applicazioni privilegi di amministratore (privilegi di root). Come giàaccennato, ai vantaggi suddetti si affiancano diversi svantaggi: ottenere accesso root significa anche poter aggirare le restrizioni di sicurezza standard del sistema operativo. Il che significa che worms, virus, spyware e trojan possono infettare il dispositivo, se non èprotetto in altro modo (lo vedremo nella sezione 3.3.3). Ci sono diversi modi tramite cui questi malware possono infettare il proprio telefono o tablet: web downloads, link malevoli, applicazioni infette scaricate da altri app store. Software malevolo eseguito con privilegi di amministratore puòavere accesso ad ogni dato contenuto nel dispositivo.

3.3 Tecniche di conﬁnamento delle applicazioni

3.3.1 Il modello Android

Il modello di sicurezza di CyanogenMod realizza il confinamento delle applicazioni allo stesso modo di Android, riutilizzando il sistema nativo del Linux Kernel di gestione dei permessi utente. Nei sistemi Linux desktop, ad ogni utente èassociato un identificativo univoco (UID - User Id) che èpoi utilizzato per specificare i permessi di accesso a file e cartelle: ogni file e cartella contiene una lista di UID, e per ognuno dei quali sono indicati i permessi (Lettura, Scrittura, Esecuzione). Android riutilizza questo sistema considerando le applicazioni come utenti e assegnando a ognuna di esse un diverso UID. In questo modo, ogni applicazione può accedere solamente ai file di sua proprietà,o eventualmente alle risorse di altre applicazioni per cui èstato esplicitamente consentito l’accesso. Come giàdetto, poichél’analisi di Android esula dagli scopi di questo report, non si scende nei dettagli implementativi di questa soluzione. Per una discussione piùapprofondita si rimanda a [42]. L’autorizzazione ad utilizzare risorse quali GPS, Fotocamera, Contatti, Risorse ecc... viene richiesta al momento dell’installazione: l’utente puòvisualizzare l’elenco dei privilegi richiesti e decidere se accettarli e proseguire con l’installazione, oppure rifiutarli e annullare. Android non presenta ad oggi una soluzione per concedere all’utente di personalizzare i permessi di una applicazione o rimuovere specifici privilegi concessi al momento dell’installazione.

42 Figura 12: Schermata di esempio di Privacy Guard 28.

3.3.2 Gestione dei permessi

CyanogenMod, pur condividendo con Android la soluzione basata sugli UID per il confinamento delle applicazioni, offre una funzione in grado di permettere all’utente di revocare selettivamente ad una applicazione i permessi concessi al momento dell’installazione. Tale funzione èrealizzata tramite l’applicazione built-in Privacy Guard. Privacy Guard èpresente in CM a partire dalla versione 10 e, oltre a quanto detto, consente anche di selezionare quali applicazioni debbano essere avviate automaticamente al bootup del dispositivo. E` stata realizzata con l’intento di portare la gestione della privacy anche nelle mani dei meno esperti, pertanto, oltre ad un menùavanzato per ogni applicazione, fornisce anche la possibilitàdi semplicemente attivare o disattivare il profilo Privacy Guard per una specifica App, impostando un profilo di sicurezza di default [43]. Privacy Guard èstato realizzato sulla base di App Ops. App Ops era una funzionalitàgià presente in versioni precedenti e nascosta, scoperta per la prima volta in Android 4.3. Il suo scopo era quello di permettere agli utenti di disabilitare specifici permessi alle applicazioni dopo l’installazione. In realtàApp Ops non fu mai pensato come uno strumento per gli utenti, ma solo per scopi di debugging [44]. E` stato rimosso nelle build di Android successive alla 4.3. Privacy Guard èora l’“App Ops” di CyanogenMod a partire dalla versione 10 [45]. Non èda escludere che gli sviluppatori di CM possano aver riutilizzato parte del codice della vecchia App Ops di Google, forse avendone anche a disposizione il sorgente intero. CyanogenMod ha dunque integrato App Ops in modo che gli utenti possano individualmente impostare su on o off i permessi per la localizzazione, la lettura dei contatti e dei log delle chiamate, la lettura del calendario, permessi su SMS/MMS ecc... per ciascuna app installata. E` stata aggiunta anche la possibilitàdi ricevere notifiche nel momento in cui una App tenta di accedere ad una risorsa bloccata. L’ultimo accesso consentito viene memorizzato e puòessere visualizzato. Poichéla rimozione dei permessi ad una applicazione non ènormalmente possibile, tale operazione potrebbe minare la stabilitàdell’applicazione interessata.

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 sua installazione su un dispositivo supportato, al posto del precedente sistema operativo Android. Eseguire questa operazione richiedeva competenze non comuni e rappresentava pertanto una difficoltàin grado di selezionare l’utenza di CM. A seguito di ciò,CM era utilizzato prevalen- temente da individui mediamente coscienti dei rischi legati alle nuove potenzialitàfornite dal sistema operativo e, in generale, all’uso di un device rooted. Ad oggi, invece, eseguire il rooting èmolto piùsemplice, grazie all’uso di tool appositi e ad una vastissima documentazione in rete. Ciòha reso questa Mod di Android alla portata di una gamma di utenti sempre piùvasta. Inoltre, come giàaccennato in precedenza, proprio in questi mesi si sta assistendo all’arrivo sul mercato dei primi dispositivi venduti con CM giàinstallato. Ciòfa capire come CM non sia più considerabile un sistema operativo di nicchia, riservato ad un’utenza mediamente competente, bens`ılo si trova nelle mani di chi, incosciente dei rischi di sicurezza associati, lo vuole sfruttare per provare funzionalitànormalmente vietate. Per queste ragioni, la 11 èl’ultima versione di CM ad essere rooted di default. In CM11 in teoria tutte le applicazioni possono eseguire operazioni con privilegi di root. In pratica, la sicurezza viene implementata a livello di applicazione: applicazioni di terze parti, tra le quali spicca Superuser, si occupano di permettere all’utente di gestire quali applicazioni possano ottenere i privilegi di amministratore. A partire da CM12, invece, di default il device non è rooted. L’arricchimento delle API fornite dal sistema operativo rispetto ad Android èin grado di permettere a molte applicazioni di fornire nuove funzionalitàpur non avendo bisogno dei privilegi di root [46]. Tuttavia, in CM12 ècomunque possibile abilitare il root del dispositivo. E` curioso notare come, al fine di evitare che un utente attivi inconsciamente il root, tale opzione sia stata nascosta: è necessario recarsi in “Settings”-¿“About phone” e toccare “Build number” piùvolte29. Il root puòessere attivato in 3 modalitàdistinte:

• Solo per le App;

• Solo per l’ADB30;

• Per entrambi.

Una volta che il root per le App èattivato, all’interno delle impostazioni di Privacy Guard per ciascuna applicazione, appariràuna nuova opzione che, come Superuser in CM11, permetterà di dare singolarmente a ciascuna applicazione il permesso di eseguire azioni con privilegi di root. Privacy Guard èin grado di intercettare le richieste delle applicazioni di eseguire il comando su, che permette di elevare i propri privilegi a quelli di superutente, ovvero amministratore, e di dare all’utente, tramite la visualizzazione di un messaggio, la possibilitàdi autorizzare o meno l’operazione. Per vedere questo meccanismo piùnel dettaglio, si consideri il caso di un’applicazione che esegue la seguente riga di codice: Process p = Runtime.getRuntime().exec(‘‘su’’);

29Le ragioni di questa scelta risiedono con ogni probabilitànel fatto che per scoprire tale funzionalitàè necessaria una ricerca in rete, che presume un minimo livello di informazione al riguardo 30Android Debug Bridge, èuno strumento a riga di comando per sistemi desktop che permette di comunicare con un dispositivo android connesso.

44 Tale riga causa la pubblicazione di un Intent 31, all’interno del gestore dei messaggi di Android, che richiede a Privacy Guard di confermare o meno l’operazione. La scelta dell’utente viene salvata per i futuri utilizzi e resta modiﬁcabile attraverso il pannello di controllo di Privacy Guard.

3.4 Store

PoichéCyanogenMod sfrutta lo stesso App store di Android, Google Play, non tratteremo in dettaglio le sue caratteristiche di sicurezza. Google Play prevede che le applicazioni siano firmate dagli sviluppatori e sottoposte a un processo di revisione in parte manuale e in parte automatico. E` importante sottolineare che, nel caso di CyanogenMod, la sicurezza a livello di store non ha grande effetto sulla sicurezza finale del dispositivo. Infatti, una delle funzio- nalitàpiùutilizzate degli utilizzatori di questo sistema operativo èla possibilitàdi installare applicazioni da fonti diverse dallo store “ufficiale”. Tali applicazioni spesso richiedono privilegi speciali (di root) per fornire quelle funzionalitàaggiuntive che l’utente medio di CyanogenMod desidera. Del resto, come detto nell’introduzione, questo èil concetto base attorno a cui ruota questo sistema operativo. Per questo motivo, la sicurezza èmolto piùnelle mani dell’utente, che deve gestire manualmente privilegi speciali, piuttosto che nei meccanismi attuati a livello di store.

3.5 Componenti di sicurezza aggiuntivi

3.5.1 Whisperpush

Gli sviluppatori di CyanogenMod hanno lavorato per lungo tempo all’integrazione nel proprio firmware di un servizio di messaggistica sicura, fino a riuscire ad introdurlo per la prima volta ufficialmente in CM11. Si chiama Whisperpush e si basa su TextSecure, un client open-source cross-platform (iOS e Android) che cifra gli SMS sia localmente che durante l’invio ad altri utenti TextSecure. Questa funzionalità,sul modello di iMessage utilizzato nei sistemi iOS, una volta abilitata ètotalmente trasparente all’utente. Nel momento in cui si invia un messaggio attraverso l’applicazione nativa per gli SMS, il sistema controlla se il destinatario possiede un client TextSecure (sia esso un dispositivo Android o iOS) e, in caso affermativo, provvede alla cifratura del messaggio e al suo invio attraverso il canale dati, altrimenti esso viene inviato come normale SMS. Il dispositivo che riceve il messaggio cifrato provvederàalla sua decifratura e a mostrarlo all’interno dell’applicazione nativa per gli SMS. Tutto ciòètotalmente nascosto all’utente, a cui non èrichiesto di eseguire uno scambio di chiavi, o di sapere che il ricevente è “online”. Il protocollo TextSecure nasce come una modifica del protocollo OTR (off the record messaging protocol), che usa chiavi effimere concordate tramite l’algoritmo Diffie-Hellman a curva ellittica. L’utilizzo di chiavi effimere èutile perchéusare sempre la stessa chiave pubblica puònel tempo aumenta la probabilitàche sia scoperta. In tal caso, sarebbe inoltre possibile decifrare tutti i messaggi inviati precedentemente con chiunque. La modifica del protocollo OTR èstata necessaria per adattarlo ad un ambiente mobile, dove fattori come lo stato della rete e i vincoli legati al risparmio energetico richiedono che la messaggistica sia di natura asincrona. In sostanza si èdovuto gestire il caso in cui la controparte non sia al momento raggiungibile (vuoi perché non ci sia copertura di rete o perchéil sistema operativo non gli permetta di essere eseguita in

31Un Intent `eun oggetto di messaggistica che pu`oessere utilizzato per richiedere un’azione a un’altra applicazione.

45 background). PoichéDiffie-Hellman richiede ovviamente uno scambio di messaggi, per adattarlo a questo contesto asincrono èstata utilizzata la soluzione che èdescritta di seguito. Dettagli del funzionamento del protocollo TextSecure:

1. Alla prima connessione al server, un client TextSecure, che si vuole chiamare A, genera preventivamente 100 messaggi per lo scambio chiavi Diﬃe-Hellman e li invia al server. Si chiamino questi “premessaggi”. La curva ellittica utilizzata `e Curve25519.

2. Un nuovo client B, che vuole inviare ad A un messaggio sicuro, pu`oora connettersi al server e eseguire l’algoritmo Diﬃe-Hellman scaricando da esso i premessaggi inviati da A.

3. In questo modo B ottiene il segreto condiviso e lo puòutilizzare per inviare al server il messaggio cifrato, insieme ai propri messaggi per il key agreement. I messaggi sono cifrati utilizzando un cifrario AES in modalitàCTR, con una chiave a 256 bit. Il server, non essendo a conoscenza del segreto di A utilizzato per generare i premessaggi, non èin grado di decifrare il messaggio.

4. Nel momento in cui A si collegher`aal server potr`ascaricare il messaggio cifrato di B e, avendo mantenuto in memoria i premessaggi inviati al server, ricavare la chiave condivisa.

3.5.2 Protezione da remoto: Device Finder

Da qualche anno, Google ha introdotto per i dispositivi Android il servizio “Android Device Manager”. Si tratta di un servizio online che da la possibilitàagli utenti di eseguire da remoto operazioni sul proprio device, principalmente a scopi di sicurezza. E` possibile ad esempio bloccare il proprio device con una nuova password, oppure eseguirne il wipe, ovvero la cancellazione di tutti i dati contenuti. Android device Manager consente inoltre di rintracciare il proprio dispositivo, se dotato di GPS. Gli sviluppatori di CyanogenMod hanno risposto alla soluzioni di Google con “Device Finder”. Dal punto di vista delle funzionalitàofferte si tratta di un servizio del tutto simile all’Android Device Manager, ma che presenta grandi differenze nella sua implementazione, volte a garantire massima sicurezza e riservatezza agli utenti [47]. Quando si utilizza Android Device Manager per rintracciare il proprio dispositivo, ènecessario autenticarsi utilizzando il proprio Account Google su un’apposita pagina web (www.google. com/android/devicemanager). Da questo, si invia al server Google la richiesta di interrogare il proprio smartphone riguardo la propria posizione. Il server Google rintraccia il dispositivo grazie a un servizio, Google Play Services, che opera silenziosamente su di esso. Il nostro device Android èprogettato per fidarsi del server Google, pertanto risponde inviando la propria posizione. Infine, il server Google passa questa posizione al nostro browser, dove èpossibile visualizzarla. Come si puònotare, il server Google agisce da intermediario. Esso vede le informazioni trasmesse in chiaro. Teoricamente potrebbe personificare una persona e chiedere al nostro device la sua posizione in qualsiasi momento lo desideri. Potrebbe essere che qualcuno al di fuori del proprietario utilizzi il server Google per avere la nostra posizione, magari in seguito ad accordi commerciali. Ovviamente ènoto che Google promette di non rivelare le nostre informazioni, ma in questo modo la nostra sicurezza consiste appunto nel fidarsi di Google, e non nell’implementazione del sistema stesso [48]. Il servizio CyanogenMod Device Finder disponibile all’interno di CyanogenMod Accounts crea invece un canale di comunicazione sicuro tra il browser e il dispositivo, in cui il server svolge solo

46 Figura 13: Confronto tra il reperimento della localizzazione del dispositivo tramite l’Android Device Manager o CyanogenMod Device Finder. In rosso si hanno le comunicazioni cifrate con la chiave simmetrica scambiata. il ruolo di intermediario, incapace di leggere il contenuto delle informazioni sensibili trasmesse. SI analizza nel dettaglio.

1. L’utente si autentica su account.cyanogenmod.org attraverso connessione sicura HTTPS, utilizzando la propria password. La password in chiaro non viene inviata al server, ne viene inviata una sua derivata.

2. Nel momento in cui viene richiesta la posizione del device, il browser genera una coppia chiave pubblica/privata, esegue l’HMAC della pubblica utilizzando la password dell’utente (non nota al server), e invia al server la chiave pubblica insieme all’hash calcolato.

3. Il server riceve questo messaggio e lo ritrasmette al device.

4. Il device, conoscendo la password dell’utente (impostata in precedenza), autentica il messaggio contenente la chiave pubblica, genera una chiave simmetrica e la manda al server, cifrata tramite la chiave pubblica appena ricevuta.

5. Il server trasmette il messaggio al nostro browser. Il server non `ein grado di leggere la chiave simmetrica contenuta all’interno del messaggio cifrato in quanto non `ein possesso della chiave privata per decifrarlo.

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

7. Da questo momento in avanti, browser e device possono comunicare attraverso un canale sicuro protetto con tale chiave asimmetrica. Il server far`asempre da intermediario, ma non potr`adecifrare i contenuti in transito.

La sicurezza di questo sistema consiste nella sua implementazione, non nella fiducia verso qualcuno o qualcosa. Quando il nostro dispositivo invia la propria posizione, nessun agente nel mezzo puòleggerla. Nessuno puòiniziare il rintracciamento se non il proprietario. Nessuno

47 puòpagare o accordarsi con gli operatori del server affinchérintraccino il dispositivo senza il nostro consenso. Si ricorda che aziende come Google e Apple, se da una parte vogliono vendere i propri prodotti come sicuri per attirare gli utenti, dall’altra hanno interessi a non proteggere la loro privacy. Questo tipo di interesse non èinvece riscontrabile in CyanogenMod, non essendo un prodotto a scopo di lucro.

3.6 Cifratura dati utente

La cifratura èutilizzata per garantire la riservatezza dei dati memorizzati su un dispositivo in caso della perdita o furto dello stesso. In CyanogenogenMod, le possibilitàdi cifratura offerte sono ereditate da Android. In questo, la cifratura per proteggere i dati èdisponibile soltanto dalla versione 3.0 (Honeycomb) in su. Per abilitare la cifratura su un dispositivo Android il filesystem deve essere montato su un dispositivo che presenta un interfaccia block device32. La cifratura èeffettuata con dm-crypt e, sebbene si parli di disk encryption, in realtànon èeseguita sull’intero disco (in quanto renderebbe impossibile il boot) ma solo sulla cartella data, contenente tutti i dati utente e delle applicazioni. Dm-crypt èun sistema per la crittografia dei dati utilizzato nel Kernel linux a partire dalla versione 2.6. Esso èparte dell’infrastruttura “device mapper”, ovvero quella che si occupa della mappatura dei dati tra unitàvirtuali di archiviazione di massa (come viste e utilizzate dalle applicazioni) e effettivo hard disk fisico. La crittografia dei dati avviene in modo trasparente al resto del sistema proprio nel corso di questa mappatura [50]. Una volta che il disco ècifrato, ogni dato creato dalle applicazioni viene automaticamente cifrato prima che sia scritto su di esso e tutti i dati letti da disco sono automaticamente decifrati prima di essere ritornati al processo che li richiede. Dm-crypt utilizza AES-128 con CBC e ESSIV SHA 256 33. La chiave di cifratura èmemorizzata sul disco in modo sicuro secondo un processo che coinvolge sia la password dell’utente sia una chiave memorizzata in hardware nel dispositivo (hardware-bound private key, HBK)34. Si mostra tale processo nel dettaglio:

1. In modo casuale viene generata una disk encryption key (DEK) di 128 bit e un sale della stessa lunghezza. Questa prima fase `eeseguita solo la prima volta che si attiva la cifratura del disco.

2. Si applica scrypt 35 alla password dell’utente e al sale della fase precedente per produrre una chiave intermedia IK1 di 256 bit. 32Un dispositivo a blocchi (in lingua inglese block device), nei sistemi operativi Unix e Unix-like, èun dispositivo su cui èpossibile effettuare operazioni di input/output per blocchi di byte di dimensione predeterminata (tipicamente dispositivi di memoria di massa come i dischi rigidi).[49] 33ESSIV èun metodo per generare vettori di inizializzazione per cifratura a blocchi utilizzata nella cifratura di dischi di memoria. ESSIV genera i vettori di inizializzazione da una combinazione del numero di settore del disco da cifrare e l’hash della chiave di cifratura [51]. 34Parliamo di una TEE key. TEE èacronimo di Trusted Execution Environment ed èuna area sicura del processore di un dispositivo che fornisce funzionalitàdi sicurezza 35Scrypt èuna key derivation function. Come PBKDF2, giàvista in 2.8, serve per derivare un segreto, nel nostro caso IK1 e IK3, a partire da un altro segreto, nel nostro caso la password dell’utente e IK2. A differenza di PBKDF2, scrypt èpiùsicura contro attacchi brute-force implementati in hardware.

48 3. A IK1 viene aggiunto del padding per portarlo alla lunghezza della HBK citata precedentemente.

4. Il risultato dell’operazione precedente `eﬁrmato utilizzando HBK per produrre IK2, di 256 byte.

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

6. I primi 128 bit di IK3 sono utilizzati come KEK (key encryption key) e gli ultimi 128 come vettore di inizializzazione IV.

7. DEK viene cifrata utilizzando AES CBC con chiave KEK e vettore di inizializzazione IV.

Si noti che l’utilizzo di HBK, introdotto solo dalla versione 5 di Android, aggiunge ulteriore protezione contro attacchi “off the box” in cui l’hard disk èestratto dal dispositivo. Il lettore potrebbe chiedersi perchéla DEK sia generata in modo casuale invece che direttamente derivata dalla password utente. La risposta risiede nel fatto che se cos`ıfosse fatto, cambiare la password utente richiederebbe di decifrare e ricifrare con la nuova DEK corrispondente tutti i dati giàcifrati. Nel modo sopra illustrato, al contrario, èsufficiente decifrare la DEK e ricifrarla con la nuova KEK [52].

3.7 Protezione dell’accesso

Figura 14: Esempio di Lock Pattern 36.

Il controllo di accesso tradizionale consiste in una sistema di sicurezza che consente l’accesso al dispositivo solo a chi conosce un segreto preimpostato. Tale segreto, richiesto per sbloccare il dispositivo dalla condizione di standby, pu`oessere 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. Lo svantaggio èche se il display trattiene facilmente le impronte lasciate dalle dita, potrebbe essere facile recuperare il percorso. Si consigliano pertanto percorsi non troppo semplici. 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 sistema piùsicuro, ma richiede generalmente piùtempo per l’inserimento.

3.8 Conclusioni

In origine, CyanogenMod rappresentava un sistema operativo accessibile ad un’utenza relativamente esperta. Ciòha permesso per anni di trascurare alcune problematiche di sicurezza, secondo un modello di fiducia verso l’utente. Indubbiamente si trattava di un sistema piùpe- ricoloso (si pensi al root abilitato di default), ma ciòera in un certo senso il prezzo da pagare per poter usufruire di certe potenzialità. La sua recente crescente diffusione, unita a un diffuso innalzamento degli standard di sicurezza richiesti dal mercato, hanno portato gli sviluppatori ad ideare una soluzione in grado al contempo di soddisfare la necessitàdi un sistema sicuro e le richieste di quella grossa fetta di utenza amante del root. L’integrazione di superuser all’interno di Privacy Guard, insieme ad un’impostazione di default che disabilita il root, rendono il sistema operativo utilizzabile in modo sicuro anche dai meno esperti. Il sistema messo in pratica da Privacy Guard era divenuto particolarmente necessario da quando, sapendo dell’incoscienza dell’utente medio nell’installare applicazioni non fidate, tra gli sviluppatori èdiventato di uso comune richiedere per la propria app un lungo elenco di autorizzazioni. si trova infatti oggi sul Google Play Store applicazioni come la torcia, che richiedono il permesso di accedere ai nostri contatti o al profilo Facebook, e ciò non sembra importare molto agli utenti. Ciòfa riflettere su quanto sia importante l’educazione del pubblico alla sicurezza e su quanto ci sia ancora molto da fare. Nel complesso, èpossibile notare un grande passo avanti rispetto ad Android: la possibilitàdi gestire in modo semplice ed intuitivo le singole risorse a cui le applicazioni possono accedere è una pietra miliare nel cammino verso un sistema sempre piùattento alla privacy degli utenti. Purtroppo, poichéle applicazioni scaricabili su un dispositivo CyanogenMod sono le stesse sviluppate per Android, esse non prevedono che i permessi possano essere revocati. In tal caso, la stabilitàdell’App èfortemente compromessa. E` importante sottolineare che l’intero codice di CyanogenMod èOpen Source, scaricabile e compilabile. Nonostante i piùnon abbiano le competenze per comprenderlo, ciòèun aspetto importantissimo in termini di sicurezza. Avere accesso al codice consente alla comunitàdi sviluppatori di setacciarlo alla ricerca di problemi da risolvere. Qualcuno potrebbe obiettare che il codice open source èun’arma a doppio taglio: di fatto èvero, trovare falle di sicurezza potrebbe anche consentire ad un attaccante di sfruttarle per scopi maligni. Tuttavia, si ricorda che il codice dei nuovi moduli viene pubblicato nelle nightly build ben prima che sia inserito all’interno delle stable release. In questo lasso di tempo, èprobabile che eventuali vulnerabilità siano scoperte. Per queste ragioni èconsigliabile di installare solo le versioni stable. Se da questo punto di vista le nightly build possono essere meno sicure in quanto non ancora testate a sufficienza, dall’altro rappresentano un potente strumento per migliorare la sicurezza: tramite queste, infatti, gli sviluppatori possono fornire agli utenti aggiornamenti rapidi contro eventuali nuove vulnerabilitàscoperte.

37In alcune versioni `epossibile modiﬁcare la dimensione della griglia

50 4 Tizen

Figura 15: Schermata Home di Tizen38

4.1 Modalit`adell’analisi di sicurezza

L’analisi di sicurezza di Tizen èla combinazione di un’analisi documentale e sperimentale. Sebbene la prima sia quella di maggiore consistenza, tramite alcuni test sperimentali èstato possibile comprendere al meglio le tecniche impiegate nel sistema. Tizen attualmente viene installato solo in alcuni dispositivi venduti nel mercato asiatico, per questo èstato possibile eseguire i test solo nella versione virtualizzata del sistema operativo. Lo sviluppo di Tizen èrecente, ma la documentazione disponibile èampia, soprattutto quella a disposizione per gli sviluppatori39 ed il Wiki40. Tuttavia le informazioni appaiono spesso frammentarie ed èevidente la necessitàdi riorganizzazione. La continua evoluzione e le nuove soluzioni proposte rendono spesso difficile il compito di analisi. Nella ricerca di informazioni hanno rivestito grande importanza anche mailing list ufficiale ed il materiale reso disponibile in occasione delle “Tizen Developer Conference”, sia nella forma

38Sorgente immagine: https://en.wikipedia.org/wiki/Tizen#/media/File:Tizen screenshot en original.png 39https://developer.tizen.org/documentation 40https://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 dei componenti di sicurezza del sistema operativo. L’analisi segue lo schema logico definito in 1.3. Da notare che le sezioni su “Tecniche di confinamento delle applicazioni” 4.5 e “Componenti di sicurezza aggiuntivi” 4.9 prevedono alcuni paragrafi di commento da parte dell’autore del report. Inoltre, le tematiche riportate in “WebGL” 4.6.2 e “XSS” 4.6.3 non trovano completo riferimento in fonti esistenti, ma sono frutto di un processo di analisi critica delle soluzioni adottate. La sezione 4.12, invece, è completamente dedicata all’esposizione dei risultati sperimentali.

4.2 Introduzione

Tizen èun sistema operativo open source per dispositivi Mobile, come smartphone e tablet, Wearable e sistemi In-Vehicle Infotainment (IVI). In futuro, punta a diventare una piattaforma open source per tutti i dispositivi dell’elettronica di consumo (netbook, TV, macchina fotografica, stampante, lavatrice). Per poter gestire la diversitàdei sistemi supportati, Tizen utilizza profili dedicati: configurazioni specifiche dello stesso sistemi operativo. L’analisi si concentra sul profilo Mobile [55].

4.2.1 Tizen, “The OS of Everything”

Nell’era precedente gli smartphone, gli utenti erano abituati ad utilizzare dispositivi differenti (cellulare, navigatore auto, macchina fotografica, TV) con la consapevolezza che le applicazioni, per quanto simili nelle funzionalità,differivano nell’usabilità. I produttori dei dispositivi sviluppavano piattaforme proprietarie e specifiche per ciascun apparecchio. Oggi nel mondo dell’“Internet of the Things”, le esigenze di connettività,compatibilitàed usabilitàrichiedono un cambiamento nell’approccio allo sviluppo. Qui nasce l’idea alla base di Tizen: una piattaforma standard, utilizzabile in diverse categorie di dispositivi con pochi cambiamenti. Inoltre, essendo open source, i produttori possono sviluppare con maggiore semplicità.

4.2.2 Storia

Nel 2010, Nokia ed Intel annunciarono MeeGo, un sistema operativo per le applicazioni Web, basato su Linux. Nokia, in seguito, usc`ı dal progetto, concentrandosi esclusivamente sullo sviluppo di Windows Phone. Intel era ancora intenzionata a sviluppare un sistema operativo ottimizzato per i propri processori, con l’intenzione di entrare nel crescente mercato mobile. Nel 2011, con il supporto della Linux Foundation, nasce Tizen. Contemporaneamente, Samsung era alla ricerca di un nuovo sistema operativo per i propri prodotti, con il principale obiettivo di diminuire la propria dipendenza da Android. Samsung si un`ıal progetto, portando con s´e soluzioni ed esperienze acquisite con LiMo e Bada, due sistemi operativi precedenti. Nel Gennaio 2012 nasce la Tizen Association42 a cui aderiscono produttori di dispositivi (OEM), operatori telefonici, aziende di videogiochi e sviluppatori di applicazioni. Rappresenta un punto di incontro per le aziende, un’occasione per poter prendere parte alle decisioni sul futuro della piattaforma. Attualmente lo sviluppo del software `eprincipalmente 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 viene presentata un’anteprima della schermata di home della nuova versione 3.0, attualmente ancora in fase di sviluppo.

4.2.3 Le architetture supportate

Attualmente sono supportate le architetture ARM ed Intel x86, sia 32 bit che 64 bit. Quest’ultima solo dalla versione 3.0 di Tizen.

4.2.4 Le applicazioni

Il package èl’entitàdi installazione in Tizen ed èun contenitore di applicazioni. Viene identifi- cato in modo univoco tramite il PackageId. Ciascuna applicazione ha associato un identificativo globalmente univoco, l’AppId ed un AppName. Tutte le applicazioni del pacchetto condividono le risorse ed i privilegi [Il sistema dei privilegi 4.5.7] definiti a livello di package. Dalla versione 2.0, Tizen supporta le applicazioni Native e Web.

• Native, scritte in C e C++, il linguaggio nativo della piattaforma. Ottimo per le performance e per il limitato consumo di memoria, inoltre vi `eun ampia disponibilit`adi librerie esistenti.

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

Dalla versione 3.0, Tizen aggiunge il supporto per le applicazioni Ibride [56]. Combinano la semplicitàdell’applicazione web con la potenza di calcolo di uno o piùservizi scritti in linguaggio nativo. Permettono un rapido sviluppo dell’interfaccia, tramite HTML5 e CSS3, ed un efficace processamento dei dati in background grazie alla vasta disponibilitàdi librerie native. Il packaging delle applicazioni Web segue le specifiche W3C43:

• Il formato del ﬁle `eun archivio ZIP.

• L’estensione del ﬁle `e.wgt.

• MIME type: application/widget.

Il packaging delle applicazioni Native ed Ibride segue invece le seguenti speciﬁche:

• Il formato del ﬁle `eun archivio ZIP.

• L’estensione del ﬁle `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 sistema possa essere utilizzato da un solo utente alla volta, pi`uutenti possono essere registrati, ciascuno con 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, Wearable e In-Vehicle Infotainment (IVI). Viene fornito un IDE (Eclipse), gli strumenti di compilazione (toolchain) ed un emulatore basato su QEMU. Per la connessione con il dispositivo, Tizen utilizza Smart Development Bridge (SDB) [58], un tool da linea di comando che agisce da intermediario tra il dispositivo o emulatore e lo strumento di debug. Permette eseguire una shell Unix da remoto, la sincronizzazione dei file e la gestione dei log [59].

4.3 Architettura

Figura 16: Architettura del sistema operativo Tizen.44

L’architettura di Tizen, mostrata in Figura 16, `ecostituita da 4 componenti chiave: il Kernel, il Core, il Framework Web ed il Framework Nativo.

4.3.1 Kernel

Dalla versione 2.0, Tizen adotta il Kernel di Linux 3.0. Contiene anche i driver per l’hardware del dispositivo.

4.3.2 Core

Contiene l’implementazione dei servizi chiave, utilizzati sia dal Framework Web che da quello Nativo. Al suo interno si possono identiﬁcare i seguenti sotto-componenti [54][60]:

44Sorgente immagine: http://www.slideshare.net/seojuyung/fa-linux-tizenﬁnalpresent

54 • Application Framework: fornisce la gestione delle applicazioni. All’avvio del dispositivo, si occupa di eseguire i servizi pre-definiti, come l’applicazione di chiamata. Gestisce la notifica di eventi di base, come il livello di batteria basso, cambiamenti nell’orientamento dello schermo e le notifiche push. • Base: contiene le librerie di sistema di Linux. Include il supporto per il database e per il parsing XML. • Connettività: fornisce tutte le funzionalitàlegate alla comunicazione su rete, come 3G, Wi-Fi, Bluetooth, HTTP e NFC (Near Field Communication). Il servizio di connettività èbasato sull’utilizzo del demone ConnMan45, sviluppato da Intel. • Grafica ed UI: gestisce lo stack dell’interfaccia grafica. Comprende EFL (Enlightenment Foundation Libraries), un sistema di gestione delle finestre basato su X11, la gestione degli input e OpenGL ES. • Localizzazione: fornisce i servizi di localizzazione (LBS - Location Based Services). E` basata su GeoClue46, un servizio che fornisce informazioni di localizzazione provenienti da differenti sorgenti, come GPS, WPS (Wi-Fi Positioning System), ID della cella telefonica e sensori. Permette inoltre di avere informazioni sui satelliti e lo stato del GPS. • Messaggistica: fornisce i servizi di SMS, MMS, Email ed Instant Messaging. • Multimedia: supporto per la visualizzazione di immagini e per la riproduzione video ed audio. • PIM (Personal Information Management): gestione dei dati dell’utente, come calendario e lista dei contatti. • Sicurezza: Sandboxing, controllo degli accessi, gestione dei certificati. Contiene i servizi server di Smack, Cynara e Content Security Framework. • System: gestisce diversi aspetti del dispositivo e di sistema: èun’interfaccia per l’accesso ai sensori, al display ed alla vibrazione. Gestisce il consumo energetico. Moni- tora gli eventi sul dispositivo, come USB, MMC, alimentatore e jack audio. Si occupa dell’aggiornamento del sistema. Infine, fornisce le funzionalitàdi sveglia e ora. • Telefonia: fornisce le funzionalitàdi comunicazione con il modem del dispositivo. Im- plementa i servizi di chiamata, messaggi, trasferimenti dati a pacchetto e informazioni di rete per UMTS e CDMA. • Web: contiene l’implementazione delle Web API di Tizen, ottimizzate per il basso consumo del dispositivo. Include il Web Runtime, per l’esecuzione delle applicazioni Web.

4.3.3 Framework Nativo

Viene rilasciato nella versione 2.0 di Tizen. Si occupa dell’installazione, disinstallazione e aggiornamenti dei pacchetti applicativi [61]. Gestisce il ciclo di vita delle applicazioni e fornisce un’interfaccia per la gestione degli eventi di sistema. Permette lo sviluppo di applicazioni native e di servizi in C++, fornendo l’accesso ad oltre 10000 API. Include il supporto per le librerie standard ed open source, come glibc, libstdc++, libxml2, Open GL R ES, Open AL R , Open MP R .

45https://01.org/connman 46http://freedesktop.org/wiki/Software/GeoClue/

55 4.3.4 Framework Web

Permette di eseguire le applicazioni che usano lo standard HTML5. Fornisce accesso a tutte le API deﬁnite 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 estendono l’accesso ai servizi di bluetooth, NFC, sveglia e messaggistica.

4.3.5 Web Runtime

Uno dei punti di forza di Tizen, èil supporto per le applicazioni Web. In tal senso, il Web Runtime èuno dei componenti di maggiore interesse nell’architettura del sistema operativo. Il Web Runtime (WRT) èil gestore del ciclo di vita di un’applicazione web. E` responsabile della loro installazione, disinstallazione ed esecuzione [62]. Il suo ruolo, per quanto simile a quello di un browser web, differisce nell’interfaccia grafica per l’assenza dei controlli di navigazione e per l’accesso all’hardware sottostante tramite le Web API. Gestisce la creazione e la distruzione dei processi relativi alle app anche in contemporanea [63]. Fino a Tizen 2.x, il web runtime era basato su WebKit. Nel Settembre 2013, inizia il progetto Crosswalk [64], per lo sviluppo di una nuova versione basata su Blink, il nuovo motore di ren- dering di Google. Presentato nel 2014, èstato inserito nella versione di Tizen 3.0. Attualmente ne viene rilasciata anche una versione per Android. La creazione di un nuovo Web Runtime èstata fortemente incentivato da Intel, che desiderava uno sviluppo piùaperto, senza “mailing list private”. Inoltre si voleva diminuire la differenza di prestazioni tra le applicazioni native e Web. Crosswalk èbasato principalmente su Blink, ma eredita anche altri progetti, tra cui Chromium, FFmpeg, Skia (per le librerie grafiche), V8 (il motore JavaScript) e la libreria Android Cordova. Vi sono poi alcuni moduli sviluppati specificatamente per Tizen, come il parser del file di Manifest [Il file Manifest 4.5.7], il runtime mode ed il Security Framework, l’implementazione delle API W3C SysApps, oltre ad un framework per l’estensione di JavaScript. Tutte le applicazioni Web in esecuzione condividono lo stesso processo Web Runtime.

4.4 Modello di sicurezza del sistema operativo

La progettazione di una soluzione di sicurezza per il sistema operativo Tizen, ha richiesto la definizione di un modello definito sulla base delle minacce offerte dal panorama mobile negli ultimi anni. In Figura 17 viene riportato uno schema riassuntivo. Le principali sfide di sicurezza sono state identificate [65] nella diffusione di applicazioni malevoli, creazione di Store non autorizzati, perdita di dati sensibili, meccanismi volti ad ingannare l’utente, nell’utente stesso ed in attacchi da remoto. A seguito èstato definito un sistema di livelli di fiducia: il kernel ètrusted, ma il secure boot è specifico del produttore del dispositivo. Il livello di fiducia di un’applicazione èlegato a quello associato allo sviluppatore. L’utente, nonostante sia il possessore del dispositivo, non èfidato. Ugualmente non lo èlo sviluppatore. Gli obiettivi di sicurezza sono stati dunque identificati nella protezione degli utenti, delle applicazioni e del sistema [66].

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 puòinnalzarli. Non puòmodificare il file system, népuòmandare segnali ai servizi di sistema, ma puòcomunque invocare azioni privilegiate per mezzo di applicazioni con sufficienti privilegi. In ultimo, èautorizzato ad installare le sole applicazioni che siano state firmate da una Trusted Certificate Chain.

4.4.2 Le applicazioni

Figura 18: Modello di sicurezza del ciclo di vita delle applicazioni.48

Proteggere le applicazioni significa proteggere il processo, il codice eseguibile, i dati, le connessioni di rete e le informazioni di run-time. Le applicazioni possono accedere all’interfaccia grafica ed ottenere l’input dell’utente. Non hanno privilegi di amministratore. L’accesso in scrittura ègarantito solo alle proprie directory.

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, èsottoposto a restrizione. L’accesso ai dati di altre applicazioni non èconsentito. Nell’elaborazione di un modello di sicurezza per Tizen, Figura 18, viene anche definito anche il modello del ciclo di vita sicuro delle applicazioni:

• Al termine della fase di sviluppo, l’applicazione deve essere firmata dallo sviluppatore per i controlli di autenticitàed integrità.

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

• In fase di installazione `esottoposta a controllo anti-virus: il sistema operativo oﬀre un’interfaccia per controllare che il pacchetto applicativo non sia malevole.

• Durante la fase di esecuzione, ciascuna applicazione èconfinata (Sandboxing) ed è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, i database, il kernel, il boot loader ed i driver hardware. I demoni di sistema sono eseguiti in un ambiente protetto e ricevono i minori privilegi possibili (sul principio least privilege). L’accesso alle connessioni di rete èristretto ed ègarantito solo ai componenti strettamente autorizzati. L’utente root èproprietario della maggior parte dei file di sistema, accessibili unicamente in sola lettura dagli altri utenti. Per il controllo degli accessi, si fa uso di una combinazione di tecniche derivanti dai modelli Discretionary Access Control [Appendice 6.5.1] e Mandatory Access Control [Appendice 6.5.2].

4.4.4 I principali componenti

Di seguito sono elencati i principali componenti di sistema che si occupano di implementare la soluzione di sicurezza in Tizen.

• Smack, Cynara e DAC : i tre pilastri della sicurezza in Tizen.

• Il sistema dei privilegi: per limitare limitare l’accesso delle applicazioni a componenti “privacy-sensitive”.

• Vasum: un Environment Separation Mechanism.

• Tizen Store: il negozio virtuale per la distribuzione di applicazioni precedentemente sottoposte a processo di revisione.

• Tizen Key Manager: un deposito sicuro, protetto da una password, per chiavi, certiﬁcati e dati sensibili.

• Content Security and Reputation Framework: per la ricerca di malware e la classiﬁcazione delle pagine Web.

• Tecniche di mitigazione delle vulnerabilit`acome ALSR e DEP.

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

Ciascuno degli elementi precedentemente elencati verr`atrattato nelle successive sezioni dell’a- nalisi del sistema operativo.

4.5 Tecniche di conﬁnamento delle applicazioni

Il sistema operativo Tizen impiega delle tecniche di conﬁnamento per eseguire le applicazioni in un ambiente ristretto, in cui politiche dettagliate limitano l’accesso a risorse ed a componenti di sistema.

Tizen 2.x L’isolamento delle applicazioni viene realizzato tramite l’utilizzo congiunto di Smack, un’implementazione del modello MAC [Appendice 6.5.2], e dell’assegnazione di permessi di accesso al file system, specifici per utenti e gruppi. Quest’ultima èuna soluzione di sicurezza classica in Unix ed èun’implementazione del modello DAC [Appendice 6.5.1]. Smack, il principale componente di sicurezza, viene analizzato nelle sezioni 4.5.1e 4.5.2, mentre l’utilizzo degli UserID e GroupID in 4.5.3.

Tizen 3.0 La struttura utilizzata per il confinamento delle applicazioni viene modificata, nel tentativo di alleggerire il ruolo di Smack all’interno del sistema operativo. Viene introdotto il nuovo modello The three domain model ed un nuovo componente di sistema, Cynara, un policy checker per il controllo degli accessi centralizzato. Le motivazioni di tale scelta e dettagli sui componenti sono trattati nelle sezioni 4.5.4e 4.5.5. Conclude la prima parte 4.5.6 in cui vengono esposte critiche riguardo alle soluzioni adottate. In 4.5.7e 4.5.8 vengono introdotti il sistema dei privilegi e la firma dei pacchetti applicativi. A seguire, in 4.5.9e 4.5.10 si applicano tutti i concetti analizzati in una descrizione sull’installazione ed esecuzione delle applicazioni. In ultimo una descrizione di Vasum 4.5.11, un Environment Separation Mechanism.

4.5.1 Smack - Simpliﬁed Mandatory Access Control Kernel

Introduzione Smack èun Linux Security Module (LSM) [24] che implementa il modello Mandatory Access Control (MAC). E` stato proposto e sviluppato da Casey Schaufler. SELinux [27], la piùnota implementazione del modello MAC, fornisce una soluzione di sicurezza completa per Linux, ma appare complesso [67]. L’approccio di Smack èpiùsemplice ed èrivolto a risolvere problemi di sicurezza piùpiccoli, richiedendo minore configurazione ed un supporto applicativo limitato. Smack èutile nelle implementazione di Sandboxing su Mobile per limitare l’accesso di un utente e di alcuni processi alle risorse. In ogni caso non èda considerare general purpose come SELinux. Smack èdisponibile nel kernel Linux dalla versione 2.6.25. Il controllo dell’accesso di Smack si fonda sull’utilizzo di etichette [68], semplici stringhe di caratteri. Ogni soggetto, l’entitàche vuole accedere ad una risorsa, ed oggetto, la risorsa, ricevono un’etichetta. Di base un soggetto puòaccedere ad un oggetto solo se le due etichette sono uguali, utilizzando un confronto case sensitive. E` comunque possibile definire delle regole accessorie per permettere diverse combinazioni.

49Sorgente immagine: https://wiki.tizen.org/wiki/File:Smack-entire-ﬂow-diagram.png

59 Figura 19: Schema di funzionamento di Smack.49

In Tizen i soggetti sono le applicazioni Web e native50, gli oggetti, i servizi e le risorse (come Wi-Fi, Bluetooth, 3G, GPS ed accelerometro), file, cartelle e socket. L’idea alla base di Smack èestremamente semplice, ma il meccanismo di controllo degli accessi tende a diventare complesso all’aumentare del numero di applicazioni e di risorse da controllare. Un numero molto alto di etichette èdifficile da gestire, ma soprattutto puòportare ad errori ed inconsistenze e ad un aumento dei tempi di risposta.

Smack in pillole

• Soggetto: qualsiasi processo in esecuzione.

• Oggetto: ﬁle, 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 `euna stringa di testo ed il suo valore non ha signiﬁcato.

• 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 speciﬁcate nella forma di tupla:

– soggetto - oggetto - accesso.

• Esistono tre etichette speciali in Tizen:

– ﬂoor: 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.

50Pi`uin generale tutti i processi in esecuzione.

60 Le etichette L’etichetta, label, èuna stringa ASCII lunga fino a 23 caratteri. Il nome associato dell’etichetta èimportante per aumentare la leggibilitàdelle regole. Le etichette assegnate alle risorse, gli oggetti, sono confrontate con quelle del processo che tenta di accedervi, il soggetto. L’impostazione predefinita prevede che l’accesso sia consentito soltanto se le due etichette sono uguali. Un amministratore, però, puòaggiungere delle regole sotto forma di tupla soggetto - oggetto - diritti di accesso. Smack non supporta le wildcard o espressioni regolari e non vale la proprietàtransitiva delle regole. Ad esempio: se a puòaccedere a b e b puòaccedere a c, questo non vuol dire che a possa accedere a c. Affinchéquesto possa valere, deve essere inserita una nuova regola specifica. Esiste inoltre un insieme di etichette Smack riservate (floor , hat ˆ, star *) alle quali si applicano regole differenti da quelle di base. Questo permette all’amministratore di limitare il numero di regole da creare per utenti e processi.

L’implementazione Smack utilizza gli extended attributes del file system51, per salvare l’etichetta associata a ciascun file. Per la configurazione, Smack usa la stessa tecnica di SELinux, definendo un file system: smackfs. Montato come /sys/fs/smackfs, fornisce diversi file che possono essere letti o scritti per la configurazione. Le regole Smack vengono salvate nel database Smack Policy 52 e caricate in memoria kernel al boot time [69]. Per effettuare delle modifiche, basta aggiungere una nuova tupla: soggetto - oggetto - regola di accesso.

Tool Sono disponibili delle versioni modiﬁcate di alcuni tool Unix per la gestione delle etichette [70][71]:

• attr: per impostare le etichette a ﬁle e cartelle.

• chsmack: per visualizzare e settare le etichette associate ad un ﬁle.

• ls -Z: visualizza le etichette associate ai ﬁle.

• sshd: associa etichette agli utenti. Rimangono settate ﬁno al logout.

• id e id -Z: per mostrare l’etichetta del processo corrente.

• ps -Z: per visualizzare informazioni sui processi, incluse le etichette Smack.

Ad esempio: per impostare l’etichetta riservata * a /dev/null si usa il seguente comando: a t t r −S −s SMACK64 −V’ ∗ ’ /dev/ n u l l

Esempio Di seguito un esempio in cui si applicano delle regole Smack accessorie per replicare i livelli di classificazione standard dei documenti governativi: Unclass per non classificato, C per classificato, S per segreto e TS per top secret. Di seguito con poche regole èpossibile stabilire la tradizionale gerarchia di accesso.

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

61 C Unclass rx S C rx S Unclass rx TS S rx TS C rx TS Unclass rx Per default, Unclass saràsolo in grado di accedere ai dati con la stessa etichetta, mentre per le regole definite di sopra, TS puòaccedere ai file etichettati S, C, Unclassed files.

4.5.2 Smack in Tizen

Livelli gerarchici di Smack ed utilizzo L’utilizzo della combinazione di etichette e regole Smack permette di definire dei livelli gerarchici di accesso [72], a ciascuno dei quali èassociato uno specifico caso d’uso. Nella tabella che segue, a livello crescente, corrisponde un accesso più ristretto. Livello Utilizzo Etichetta soggetto Etichetta oggetto Accesso 1 Accesso illimitato qualsiasi * rwx 2 Condivisione file qualsiasi rx 3 Sandboxing specifica la stessa del soggetto rwx 4 Controllo accessi specifica specifica basato su regole

Il primo livello viene impiegato per fornire accesso illimitato a quelle risorse utili a tutti gli applicativi. Questo permette un grande risparmio di regole Smack, che altrimenti sarebbero dovute essere definite per ogni soggetto Smack (applicazione). Ad esempio, i direttori /dev/null e /dev/zero ricevono l’etichetta star (*), dunque hanno accesso illimitato. Il secondo livello viene utilizzato per la condivisione dei file tra le applicazioni. Associare alle cartelle condivise l’etichetta floor ( ), permette a qualsiasi processo l’accesso in lettura ed esecuzione ai dati contenuti. Inoltre, le cartelle /lib, /bin, /usr/lib, /etc, /dev ricevono tutte l’etichetta floor (“ ”). Il terzo livello gerarchico viene impiegato per l’implementazione del Sandboxing delle applicazioni: se le etichette del soggetto e dell’oggetto sono le stesse, l’accesso dell’applicazione ai propri dati viene gestito senza la necessitàdi definire altre, piùspecifiche, regole Smack. L’ultimo e piùrestrittivo livello, il quarto, viene utilizzato per la gestione dei permessi associati alle applicazioni. In Tizen 2.x, al momento dell’installazione [4.5.9] viene creato un nuovo dominio per il pacchetto applicativo e vengono definite delle regole per limitare l’accesso alle sole risorse consentite.

4.5.3 UserID e GroupID

Tizen 2.x Non èun sistema operativo multi utente, ma l’utilizzo degli UserID e GroupID e l’assegnazione dei permessi di accesso al file system rappresenta un’importante componente nel confinamento delle applicazioni [73]. Questa soluzione di sicurezza, classica di Unix, è un’implementazione del modello DAC [Appendice 6.5.1]. In Tizen 2.x esistono 3 utenti: root (UID 0), app (UID 5000) e developer (UID 5100). Tutte le applicazioni sono eseguite dall’utente app (userID 5000), nessuna dall’utente root (user ID 0). La shell di sdbd 53 viene invece eseguita con user ID 5100. 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 ﬁle e cartelle:

Descrizione Permessi Conﬁgurazione di base per tutti i ﬁle 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 UserID e GroupID cambia, ma non sono disponibili informazioni a riguardo.

4.5.4 The three domain model

Per poter comprendere le motivazioni alla base del cambiamento attuato da Tizen 3.0 nel modello di confinamento delle applicazioni, vengono qui anticipati alcuni concetti sui privilegi delle applicazioni, che verranno poi spiegati in dettaglio nella successiva sezione 4.5.7: “Il sistema dei privilegi”. In Tizen, i privilegi delle applicazioni vengono specificati facendo riferimento a servizi astratti, come “telefonia”, piuttosto che indicando dettagliatamente le risorse di sistema effettivamente usate per implementare la soluzione. Se da un lato questa scelta facilita la definizione dei permessi nello sviluppo delle applicazioni, dall’altro rende complicato il modo in cui i servizi astratti vengono mappati nei diversi componenti di sistema utilizzati.

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

Tizen 3.0 Viene introdotto un nuovo modello di controllo degli accessi compatto, the three domain model: tre domini, tre gruppi di etichette ed alcune regole gi`adeﬁnite [76]. In Tizen esistono fondamentalmente due tipi di dati:

• Dati utente di propriet`adell’utente ﬁnale.

• Dati di sistema che non possono essere cambiati dall’utente ﬁnale.

I processi utente devono avere accesso ai dati del sistema e comunicare con i processi di sistema. Una soluzione pratica `equella di dividere i dati di sistema in una parte accessibile in lettura da chiunque ed in una che comunica con il processo utente. Il risultato sono i tre domini:

63 User: per i processi ed i dati utente.

System: per i processi di sistema ed i loro dati privati.

Floor: per i dati di sistema pubblici.

L’accesso intra-dominio èlibero, ma quello cross-dominio èristretto e strettamente controllato. Ad ogni dominio èassociato un gruppo di etichette Smack. Le principali sono:

• User e User::App::$app id, associate al dominio User.

• System, associata al dominio System.

• ﬂoor, * star e ˆ hat, associate al dominio Floor, mantengono lo stesso signiﬁcato spiegato in 4.5.1.

A differenza della versione precedente, dove un nuovo dominio veniva creato ad ogni installazione, in Tizen 3.0 i tre domini di sicurezza sono creati preventivamente. Da notare che ogni applicazione installata, riceve ancora una propria etichetta, ma il dominio di appartenenza rimane quello User. L’adozione del “Three Domains Model” ha permesso di rendere le regole Smack piùchiare e piùsemplici da gestire. Inoltre, ha consentito di velocizzare il sistema, sia al tempo di boot (nella fase di loading delle regole), sia a run-time (nel processamento delle regole).

Figura 20: I pilastri del modello della sicurezza di Tizen 3.0.56

Nonostante questa soluzione semplifichi il controllo degli accessi, permettendo di ridurre il numero di etichette, la bassa granularitàdei tre domini, non fornisce un controllo dell’accesso alle risorse sufficientemente dettagliato per garantire la protezione del sistema e di ciascuna applicazione. E` stato quindi necessario introdurre un nuovo componente, Cynara, con la funzione di policy checker: controllare i privilegi delle applicazioni che tentano di accedere alle risorse ed alle API “privacy-sensitive”. In Tizen, l’utilizzo congiunto di UserId e GroupID (DAC), Smack e Cynara da origine ai “I tre pilastri della sicurezza di Tizen 3.0”, Firgura 20.

4.5.5 Cynara

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

56Sorgente immagine: https://wiki.tizen.org/wiki/File:SmackCynaraDAC 443 418.png 57Sorgente immagine: https://wiki.tizen.org/wiki/File:CynaraInputData 842 504.png

64 Figura 21: Le sorgenti che popolano il database di Cynara.57

I servizi di sistema necessitano di un meccanismo di controllo per verificare che chi vi accede abbia privilegi sufficienti.58 In Tizen 2.x questa funzione veniva offerta da un set molto dettagliato di regole Smack. La semplificazione introdotta dal “Three domain model” [4.5.4] rende necessario un nuovo componente che memorizzi i privilegi associati a ciascuna applicazione ed esponga una semplice chiamata API per il controllo delle policy di accesso. Cynara fornisce un database per memorizzare i permessi associati ad un’applicazione, mantiene il complicato mapping tra i “privilegi astratti” e le risorse di sistema ed espone una libreria client leggera per rendere il controllo degli accessi semplice [78].

Cynara in dettaglio In riferimento alla Figura 21, il database di Cyanara viene popolato utilizzando diverse sorgenti:

• Le regole built-in deﬁnite dall’OEM.

• Le regole imposte dall’amministratore di sistema.

• Utilizzando il ﬁle Manifest dell’applicazione durante la fase di installazione [ulteriori dettagli in 4.5.9].

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

Nel database, ogni applicazione univocamente identificata da un’etichetta Smack, ha associata un lista di privilegi. I servizi di sistema fanno richiesta a Cynara per il controllo dell’accesso fornendo una tripletta: utente, applicazione e permesso.59 Cynara èottimizzato per minimiz- zare i tempi di risposta, tramite cache dei risultati. Il tempo medio per un controllo di accesso èinferiore ai 10 ms, contro i 30ms medi delle implementazioni alternative [79]. In figura 22, viene mostrato un esempio di utilizzo di Cynara. Quando un’applicazione in esecuzione richiede l’accesso ad un componente di sistema, ad esempio il GPS, il componente

58Vengono qui anticipati alcuni concetti sui privilegi delle applicazioni, che verranno poi spiegati in dettaglio nella successiva sezione 4.5.7: “Il sistema dei privilegi”. 59Cynara `epensato 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 database delle policy. Per un controllo piùfine, nel processo decisionale puòintervenire un un “agent esterno”, implementato nella forma di plug-in. Ad esempio, si potrebbe usare un popup, in cui l’utente puòscegliere se consentire l’accesso ad una determinata risorsa. In ogni caso l’idea alla base di Cynara èquella di offrire una risposta precisa: permesso o non permesso. Se non viene consentito l’accesso ad una risorsa, o ad un’API privilegiata, a livello applicativo viene generata una SecurityError Exception.

4.5.6 Commenti sul modello del controllo degli accessi in Tizen

Di seguito vengono riportate alcune critiche sul modello del controllo degli accessi in Tizen, prendendo riferimento da quanto emerso nella presentazione uﬃciale [78].

• Tizen 2.0 utilizza politiche di sicurezza del sistema scritte come un insieme di regole Smack, nel tentativo di isolare le singole applicazioni vengono creati dei domini separati ad ogni nuova installazione. La stessa soluzione viene adottata sia in SELinux che in AppArmor, per questo Smack viene ritenuto essere, in parte, la reinvenzione di una soluzione esistente.

• Nella presentazione di Cynara [78], Tomasz Swierczek´ ha annunciato che le performance di Cynara sono migliori rispetto ad altre soluzioni esistenti, come ad esempio Polkit. Quest’ultimo, in particolare, viene indicato come caratterizzato da scelte architetturali carenti per l’utilizzo di Json e XML per lo storage e l’assenza di cache. Questi sembrano piùproblemi implementativi, che architetturali. In ogni caso, una soluzione studiata appositamente per un sistema operativo mobile, come Cynara, puòavere alcuni vantaggi, anche in termini di velocità.

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

61tramite l’API cynara check()

66 Figura 23: Controllo dei privilegi nel men`uimpostazioni.62

non `ela soluzione [80]: per troppo a lungo gli utenti sono stati abituati a rispondere automaticamente si ad ogni dialog di conferma.

Nonostante Smack presenti alcuni elementi in comune con le soluzioni esistenti, risulta essere cos`ı semplice, da rimanere molto interessante. Solo con il tempo si sapràse la verifica, i permessi o le etichette di Smack possono essere falsificati da applicazioni malevoli. Con permessi falsi, un’applicazioni potrebbe accedere ai demoni di servizio ed ottenere informazioni sensibili senza il consenso dell’utente. Inoltre potrebbe avere accesso o modificare informazioni in altre applicazioni. Il modello di sicurezza crollerebbe.

4.5.7 Il sistema dei privilegi

Tizen fornisce un controllo sull’accesso alle API ed ai servizi privacy-sensitive il cui utilizzo può compromettere la privacy dell’utente e la stabilitàdel sistema. Alcuni servizi sono sensibili per la sicurezza dell’utente e del sistema e non dovrebbero essere disponibili per tutte le applicazioni. Per esempio, leggere un SMS èun’operazione sensibile: i messaggi in arrivo potrebbero contenere informazioni riservate e quelli in uscita potrebbero comportare una spesa per l’utente [Introduzione 1.2.1]. Quindi alcune funzionalitànon devono essere disponibili per tutte le applicazioni, ma solo per quelle per cui l’utente ha approvato durante l’installazione, o a run time, il loro utilizzo. Le applicazioni giàinstallate dall’OEM, sono invece considerate trusted dal sistema operativo. La maggior parte dei privilegi sono legati all’utilizzo delle API corrispondenti. Altri, come “privilege/internet” o “privilege/mediastorage”, sono puramente basati su una risorsa. Il livello di privilegio associato alle API èdefinito nel file di configurazione delle Policy di Tizen. Membri della Tizen Association, possono cambiarle in accordo con le loro necessità,nonostante sia un’operazione molto rischiosa dal punto di vista della sicurezza del sistema operativo.

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 concessi dalla piattaforma Tizen, dipendono dalla tipologia di firma utilizzata. In fase di installazione, il gestore dei pacchetti confronta la firma utilizzata dal distributore dell’applicazione, con quelle disponibili nel sistema per i differenti livelli di privilegio [ulteriori dettagli in 4.5.8]. Il risultato del confronto definisce il massimo livello di privilegi disponibile per l’applicazione installata ed il relativo accesso alle API. Nella versione 2.2.1[81] di Tizen èstato aggiunto il pannello Privacy Manager nel menù Settings. Selezionando un applicazione èpossibile, a posteriori, la modifica delle regole di accesso63. In Figura 23 èmostrata la schermata per l’applicazione TestApp. La modifica dei privilegi associati ad un’applicazione ha conseguenze sul funzionamento dell’eseguibile: quando un’applicazione tenta di utilizzare le API privacy-sensitive i cui privilegi di utilizzo sono stati bloccati nelle impostazioni di privacy del dispositivo, viene generata un’eccezione64 nel codice. E` importante che in fase di sviluppo l’applicazione abbia gestito correttamente tali eccezioni. Le linee guida di Tizen [82] consigliano di visualizzare un messaggio all’utente per spiegare il motivo per cui l’azione èstata interrotta.

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

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

• Public: `eil livello minimo, garantito a tutte le applicazioni sviluppate con il SDK. E` aperto a tutti gli sviluppatori.

• Partner: accessibili solo dagli sviluppatori registrati come partner presso il Tizen Store.

• Platform: disponibili solo per gli sviluppatori che lavorano per il consorzio di Tizen. Comprende le API utilizzate dal framework e dalla piattaforma Tizen.

63La modiﬁca dei privilegi tramite il Privacy Manager comporta, in Tizen 2.x, un aggiornamento dei database Privilege DB e Smack Policy (trattati in 4.5.9). A partire da Tizen 3.0, la modiﬁca dei permessi di un’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 primi sono associati alle applicazioni native, i secondi alle applicazioni web. Di seguito alcuni esempi di privilegi nativi: • calendar.read: l’applicazione puòleggere gli eventi del calendario (livello public). • appmanager.kill: l’applicazione puòchiudere altre applicazioni (livello platform). Un esempio di privilegi web: • packagemanager.install: l’applicazione puòinstallare o disinstallare pacchetti applicativi (livello platform). Una lista esaustiva dei privilegi èdisponibile nella guida per gli sviluppatori di Tizen65 66.

4.5.8 Firma delle applicazioni

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

La firma dell’autore èil meccanismo di verifica dell’appartenenza dell’applicazione allo sviluppatore ed assicura l’integritàdel pacchetto applicativo, cos`ıcome èstato inviato dallo sviluppatore. Permette di creare una trusted-relationship tra un’applicazione ed una sua nuova versione, fondamentale nel processo di aggiornamento. Inoltre consente di instaurare una trusted inter-application-communication, un meccanismo di comunicazione tra le sole applicazioni firmate con la stessa chiave dello sviluppatore, all’interno dello stesso dispositivo. Il certificato dello sviluppatore, puòessere creato tramite il Tizen IDE.

La firma del distributore viene applicata dal distributore delle applicazioni, come il Ti- zen Store (trattato in 4.7), per certificare la provenienza e verificare l’integritàdel pacchetto applicativo, cos`ıcome èstato pubblicato sullo Store. Fornisce la garanzia che l’applicazione abbia superato il processo di revisione e determina il massimo livello di privilegi concessi. Ad esempio, se l’applicazione viene firmata con un certificato di livello pubblico, allora avràaccesso ai soli privilegi di livello pubblico. In fase di sviluppo delle applicazioni, èpossibile creare una coppia di certificati temporanei per ottenere il livello di privilegi partner e platform [86]. Tuttavia, a differenza dell’emulatore, per effettuare il test su dispositivi reali ènecessario che le “Opzioni per gli sviluppatori” siano state abilitate nel dispositivo. Successivamente, in fase di distribuzione dell’applicazione, la firma temporanea saràsostituita da quella del reale canale di distribuzione, come ad esempio il Tizen Store. La firma delle applicazioni segue le specifiche W3C67: • L’algoritmo di firma raccomandato èRSA con SHA 256. • La lunghezza raccomandata della chiave per RSA èdi 4096 bit. • Il metodo di digest raccomandato èSHA-256. • Il formato di certificato raccomandato èX.509 versione 3 come specificato in [RFC5280].

65https://www.tizen.org/privilege 66https://wiki.tizen.org/wiki/Security/Tizen 2.X Privileges#Privilege Categorization 67http://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, eﬀettua il controllo delle ﬁrme dello sviluppatore e del distributore sul pacchetto applicativo.

2. Viene effettuato il parsing del file di Manifest, al fine di controllare che i privilegi richiesti dall’applicazione siano compatibili con la tipologia di firma utilizzata dal distributore.

3. Si procede alla copia dei file eseguibili nella cartella bin nella home dell’applicazione70. Poichél’Installer viene eseguito dall’utente root, di default tutti i file sono di proprietàdi root [73], ma in seguito lo UserId ed il GroupId dei direttori data e tmp sono settati ad app [rif 4.5.3]. Infine l’installer setta l’etichetta Smack per tutti i file dell’applicazione uguale all’ApplicationID (ad eccezione della cartella shared a cui viene associata l’etichetta floor). Per default, un’applicazione èquindi in grado di accedere a tutte le sue risorse.

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

5. I privilegi dichiarati dall’applicazione sono convertiti in regole Smack sulla base di alcuni template deﬁniti in smack-privilege-conﬁg 71 [88].

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

68Sorgente immagine: https://wiki.tizen.org/wiki/File:Access control architecture.png 69Durante 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 installazione, viene introdotto un nuovo componente: Cynara [rif 4.5.4e 4.5.5]. Il processo di installazione rimane simile, con la differenza dell’introduzione del Security Manager [89], un demone di sistema privilegiato, incaricato di settare correttamente gli attributi di file e cartelle, di assegnare le etichette Smack e di popolare il database di Cynara.

4.5.10 Esecuzione delle applicazioni

Figura 25: Schema dei passaggi per l’esecuzione di un’applicazione Nativa.72

Tizen 2.x Il launchpad daemon `eil demone, eseguito dall’utente root, che interviene nella creazione di un nuovo processo [90] ed `eil processo padre di tutte le applicazioni nel sistema operativo. Di seguito le fasi necessarie per il lancio di un’applicazione Nativa, Figura 25:

• Il launchpad daemon crea un nuovo processo ﬁglio, tramite la system call fork().

• UserId e GroupId del nuovo processo vengono impostati a 5000 (app)[4.5.3].

• Viene settata l’etichetta Smack corretta, utilizzando le libprivilege-control API [87].

• A seguito della chiamata alla system call exec(), inizia l’esecuzione dell’applicazione richiesta.

• Durante l’esecuzione le applicazioni sono conﬁnate tramite le tecniche descritte in 4.5.

Il caso di un’applicazione Web, si diﬀerenzia 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.png 73L’eseguibile di un’applicazione Web `eun link simbolico a /usr/bin/wrt-client.

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

Tizen 3.0 Durante la fase di lancio, il Security Manager [89] setta l’etichetta Smack ed il GroupId (DAC) del nuovo processo creato, in modo tale da garantire al processo l’accesso ai propri file. A run-time l’applicazione potrebbe richiedere l’accesso ad ad un servizio di sistema o al file system. Nel primo caso l’etichetta Smack associata al processo applicativo viene usata da Cynara per controllare se l’accesso possa essere garantito. Nel secondo, il filesystem utilizza gli attributi UserId e GroupID e l’etichetta Smack per effettuare gli opportuni controlli.

4.5.11 Vasum

Figura 26: L’architettura di Vasum con due zone in esecuzione.74

Tizen implementa il meccanismo di Sandboxing delle applicazioni basandosi principalmente sui modelli del controllo degli accessi MAC e DAC. Questa soluzione permette una separazione a livello dell’applicazione, ma l’ambiente di esecuzione rimane unico. Vasum [91] èun Envi- ronment Separation Mechanism basato su Linux Containers/LXC (dettagli in Appendice 6.6), che consente di avere su uno stesso device piùambienti di esecuzione separati, chiamati zones, ciascuno dei quali esegue virtualmente una copia del sistema operativo Tizen. Il principale beneficio offerto èquello di avere ambienti di esecuzione separati per il test di applicazioni malevoli, per lo sviluppo di applicazioni che necessitano di configurazioni specifiche e per limitare le funzionalitàdi un dispositivo dato in dotazione. Attualmente Vasum èancora in una fase di sperimentazione e non èstato inserito nell’Open Build Service (OBS)75, il servizio per la raccolta dei pacchetti software di una release del sistema operativo. Il modello logico di Vasum prevede l’esecuzione contemporanea di una versione nativa del sistema operativo, host, e di alcune istanze virtualizzate, guest. Tizen nativo si occupa di:

74Sorgente immagine: https://wiki.tizen.org/wiki/File:VasumDiagram v1.png 75https://build.tizen.org/project/show?project=Tizen%3AMobile

72 • Gestire le risorse hardware del dispositivo.

• Eseguire alcuni servizi critici che ha senso siano presenti in una sola istanza per ciascun dispositivo, tra cui il server Vasum, descritto in seguito.

• Gestire il ciclo di vita e le risorse delle zone.

• Mediare nella comunicazione tra zone e ricevere da ciascuna le richieste per le operazioni privilegiate, come l’avvicendamento della zona in foreground.

Tizen virtualizzato in una zona, `eincaricato 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 conﬁgurazioni di ciascuna zona.

• Fornire i meccanismi di condivisione intra-zona.

Installare le applicazioni nel guest, richiede che tutte le operazioni privilegiate, come settare le etichette Smack, siano eseguite dall’Installer [rif 4.5.9], con il quale l’applicazione di installazione specifica di una zona comunica su socket. L’Installation Service, rispetto alla versione standard di Tizen, necessita di alcune modifiche per supportare la gestione delle zone in Vasum. Dal punto di vista implementativo, figura 26, Vasum ècostituito da una componente Server e da una Client, di seguito analizzate.

Server Il server Vasum `eun servizio systemd che implementa la maggioranza delle funzionalit`alogiche, di sopra descritte.

• Per motivi di sicurezza, viene eseguito da un utente non root.

• Espone un set di API utilizzabili sia dai servizi in esecuzione sull’host, che da quelli in una zona.

• Si occupa di mantenere la comunicazione sia con i client, che con i bus rispettivi di ciascuna zona e permette di contattare altri servizi in esecuzione sull’host, come Cynara[rif 4.5.5].

• Gestisce il ciclo di vita delle zone (start, stop e restart), l’avvicendamento di quella in esecuzione e mantiene la configurazione di ciascuna. La decisione sullo scheduling delle zone, puòessere presa autonomamente, o essere richiesta esplicitamente da un servizio di sistema, usando la chiamata ad un’API specifica o dall’utente, tramite il triplo click sul bottone di home.

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

• Fornisce un set di API per la comunicazione intra-zona, messaggi broadcast per la comunicazione tra zone e funzione di relaying per i client in ascolto.

73 Client Il client comunica con il server Vasum tramite alcune API.

• Permette a servizi ed alle applicazioni in esecuzione in una zona di ottenere il controllo, anche se parziale, sul dispositivo.

• Consente ad un servizio, in esecuzione sull’host, di comunicare con le applicazioni all’interno di una zona.

• Include un meccanismo di notiﬁca per l’utente, per informarlo nel caso in cui una zona in background richieda la sua attenzione.

• Comprende un’applicazione graﬁca che consente la gestione delle zone da parte dell’utente: creazione, distruzione ed impostazione dei privilegi.

4.6 Criticit`aprogettuali ed implementative delle applicazioni

In questa sezione vengono trattate alcune tematiche che introducono delle potenziali debolezze nelle applicazioni in Tizen. In 4.6.1, viene presentata una soluzione proprietaria per la conversione delle applicazioni da Android a Tizen. Se da un lato risulta essere molto attraente per l’aumento di interesse verso la piattaforma, dall’altro non sono noti i risvolti di sicurezza. Viene in seguito trattato l’utilizzo OpenGL nelle applicazioni Web, 4.6.2, un problema ipotiz- zato in [92], su cui l’autore del report ha voluto indagare piùapprofonditamente. A concludere, 4.6.3, un’esposizione sul Cross Site Scripting nelle applicazioni Web. Un problema giànoto alla comunitàTizen [92], ma per cui non sono state sviluppate contromisure, nésembra che ve ne siano in progetto.

4.6.1 Conversione automatica della applicazioni

In occasione della Tizen Developer Conference del 2013 [93], Infraware ha presentato PAG Service [94], una soluzione proprietaria per la conversione automatica di applicazioni esistenti per Tizen. Seconda l’azienda, il processo di conversione di applicazioni esistenti ha innumerevoli vantaggi: permette di ridurre i costi di progetto, i tempi di sviluppo e di avere un time-to-market bassissimo. Gli sviluppatori possono sviluppare a basso costo e pubblicare sul Tizen Store in tempi brevi. Inoltre, per la piattaforma Tizen, avere piùapplicazioni a disposizione, significa rendere il sistema operativo piùcompetitivo. Gli utenti non percepiscono differenze tra le applicazioni native e convertite e possono accedere a software di alta qualitàe performance, indipendentemente dalla piattaforma utilizzata. Attualmente la maggior parte degli sviluppatori per applicazioni mobili si concentra su iOS ed Android. Inoltre, quest’ultimo detiene la maggiore quota di mercato. Uno strumento di conversione automatica delle applicazioni disponibili per Android in Tizen, risulterebbe molto interessante. Android fornisce un ambiente di esecuzione “Hardware Indipendent”, basato sull’utilizzo di una macchina virtuale. Il semplice porting dell’Android Runtime permette di eseguire le applicazioni

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 pi`u,se le i pacchetti applicativi vengono convertiti (repackaged) nel formato TPK di Tizen, `epossibile anche l’upload sul Tizen Store. Il processo richiede 3 fasi:

• Verifica: tramite POLARIS R App Verifier, si controlla se l’applicazione èadatta alla conversione.

• 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 PAG in Tizen, ﬁgura 27.

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

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

4.6.2 WebGL

WebGL èuna tecnologia multipiattaforma che fornisce un’API low-level per la gestione della grafica 3D. Nel Maggio e nel Giugno 2011, Context Information Security pubblicòdue report [96][97] che evidenziarono alcune criticitàsulla sicurezza di WebGL, dimostrando come fosse

75 Figura 28: Esempio di attacco a WebGL con escalation of privileges.77 possibile ottenere degli screenshot dal dispositivo della vittima, con la possibile conseguente perdita di dati sensibili. In seguito, Microsoft scelse di terminare il supporto di WebGL nel proprio browser [98]. Tizen, nelle applicazioni Web, espone le API per accedere direttamente a WebGL. Di seguito sono presentati alcuni punti di approfondimento:

• Il supporto dei browser per WebGL espone le funzionalitàhardware direttamente sul web. WebGL permette ad applicazioni web (tipicamente untrusted) di interagire direttamente con i driver grafici (che operano in Kernel mode). La superficie di attacco di WebGL è molto ampia ed espone codice privilegiato e non sufficientemente robusto. Il supporto browser per WebGL richiederebbe ai driver grafici delle garanzie di sicurezza di cui mai si era occupati fino ad ora. Se prima gli attacchi potevano risultare in un “escalation of privileges” locale, ora lo possono diventare da remoto. Inoltre èlecito aspettarsi dei bug solo su alcune piattaforme con hardware video specifico, facilitando attacchi mirati. Nonostante OpenGL abbia delle funzionalitàaggiuntive per permettere ai driver video una validazione del codice 3D, queste sono da ritenersi incomplete. In Figura 28 sono mostrate le fasi di un esempio di attacco WebGL.

• La responsabilitàdei software di terze parti. La dipendenza del supporto browser per We- bGL dai software di terze parti, ètroppo alta per poter assicurare una navigazione web sicura. I problemi di sicurezza potrebbero non manifestarsi direttamente nelle API di We- bGL, ma nei vari componenti di sistema OEM o distribuiti da vari Indipendent Hardware Vendors. Gli sviluppatori dei driver video non hanno mai affrontato questo problema, essendo in genere esposti a codice trusted (quello del sistema) ed avendo fiducia che gli

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

76 sviluppatori 3D non attaccassero le vulnerabilit`a. Inoltre il modello di aggiornamenti utilizzato nei driver delle schede video, caratterizzato spesso da update annuali, non soddisfa le esigenze di un robusto “processo di aggiornamenti di sicurezza”.

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

4.6.3 XSS

XSS èuna vulnerabilitàCross-Browser, Cross-Piattaforma e Cross-Sistema operativo che permette di inserire ed eseguire codice Javascript lato client. Ne sono affette le applicazioni web che elaborano dati provenienti da sorgenti non fidate e che non effettuano gli opportuni controlli. Un esempio èil campo di input di un form: se i dati non sono correttamente filtrati (ad esempio rimuovendo il tag