Pillole di Windows Phone 8: Chambers&Capabilities

windows-phone-logo-largeIn questa serie di articoli andremo a trattare i meccanismi di sicurezza su cui è stato costruito Windows Phone e vedremo anche come effettuare l’hardening del sistema.
Purtroppo non mi è possibile testare di persona le caratteristiche più intricanti come bitlocker, le politiche di gestione delle password ed i trigger per il wipe out del dispositivo: come un errato numero di tentativi di login. Non posso testare queste features poiché non ho un account aziendale o comunque un collegamento ad Exchange Server. Se qualcuno è in grado di fornirmi le informazioni necessarie ad attivare questi sistemi di sicurezza pur da utente semplice gliene sono grato e potrò trattare meglio l’argomento.

Per il momento, partiamo con un interessante modello di progettazione: Chambers & Capabilities, per capire meglio come vive il software sul nostro smartphone.

Le Chambers&Capabilities sono una interessante caratteristica dell’implementazione del modello applicativo di Windows Phone.
In maniera non molto dissimile dal design del sistema Android (ne ho parlato nel secondo articolo della serie Mettere in sicurezza Android) ma decisamente più restrittivo, il sistema delle Chambers & Capabilities riassume il concetto di sandboxing utilizzato per isolare le applicazioni e proteggere l’os dall’esecuzione di codice malevolo. Andiamo ad analizzarle nella loro funzionalità.

Le Chambers rappresentano lo spazio di lavoro di una applicazione. Una certa applicazione può accedere alle sole risorse che rientrano nella propria Chamber (camera). Ad esempio, l’applicazione che ci consente di leggere e scrivere i nostri articoli memorizzerà il testo che scriviamo nel proprio spazio di memorizzazione che l’OS isolerà dallo spazio di memorizzazione di altre applicazioni. Non c’è una interazione diretta tra l’applicazione ed il filesystem. Il filesystem vero e proprio è ad un layer inferiore allo spazio di memoria che contiene i file letti e scritti da un programma a livello utente.
Fondamentalmente una certa applicazione di norma non potrà accedere ai dati di un’altra app, a meno che questa non fornisca di proposito una interfaccia per accedere ai propri dati (ciò accade ad esempio per la rubrica, le foto ecc… ). Tuttavia per ottenere tali risorse l’utente dovrà comunque dare il privilegio, al software che è client verso queste risorse, di usare una certa Capability.
Facciamo l’esempio dell’invio di un documento .doc attraverso la posta elettronica.
L’applicazione di posta elettronica non può accedere allo spazio di memorizzazione dell’applicazione Office. L’applicazione Office è pertanto l’unica a poter accedere ai suoi documenti e questo è stabilito ad un layer di più basso livello rispetto all’applicazione. Office dovrà quindi richiedere al sistema, previa autorizzazione dell’utente, la possibilità di inviare un documento attraverso la posta elettronica.

La sicurezza a questo punto è nel fatto che, scaricando malauguratamente una applicazione malevola, questa non potrà utilizzare o leggere i nostri ducumenti (poiché l’os gestisce il meccanismo di isolamento dei dati tra le diverse applicazioni) a meno che essa non vada ad operare ad un più basso livello ma questo a sua volta è impedito da altri meccanismi di protezione (ad esempio non è possibile iniettare codice malevolo nel kernel sfruttando qualche vulnerabilità, poiché verrebbe a fallire il controllo di coerenza del sistema di trusted boot che è ad un livello ancora inferiore rispetto al sistema operativo).

Come avrete intuito però le applicazioni non sono rigidamente confinate nella propria Chamber. La flessibilità operativa è data dal meccanismo delle Capabilities.
Le Capabilities di Windows Phone 8 consentono ad una applicazione di accedere ed usare determinate risorse. Concedetemi il parere personale: sono uno strumento fantastico!

Esempio di visualizzazione dei privilegi richiesti da una app nel windowsphone app store

Esempio di visualizzazione dei privilegi richiesti da una app nel windowsphone app store

Fondamentalmente una certa applicazione per usare il dispositivo sfrutta funzionalità implementate dalle API di Windows Phone. Queste funzionalità possono conferire la possibilità di usare il traffico dati (accedere ad internet in soldoni), scrivere e leggere dalla memoria SD, accedere ai nostri contatti o aprire un flusso dal microfono o dalla fotocamera e mille altre cose.
Nel momento in cui un programmatore usa nel suo software l’API della geolocalizzazione GPS, automaticamente il sistema saprà che quel programma tenterà di prendere dati di geolocalizzazione ed inserirà questa richiesta al momento dell’installazione della app.
L’utente, quindi, prima di installare l’applicazione potrà scegliere di persona se le richieste del software collimano con i propri requisiti di sicurezza, andando  addirittura oltre i controlli che Microsoft effettua sulle applicazioni prima di renderle idonee per la pubblicazione nel proprio store.

Ad esempio io non installerei mai e poi mai una applicazione “bussola” sul mio smartphone che richieda l’utilizzo del servizio dati e magari della rubrica contatti. Se devi mostrare una bussola devi accedere ai sensori, non ad internet o alla mia rubrica personale: non mi convince! Magari è una applicazione che dalla rete scarica advertisement e lo invia anche ai miei amici o peggio ai miei colleghi di lavoro.

Dato che questo meccanismo di Capabilities è comunque molto affidabile, voi avrete la sicurezza che difficilmente una applicazione potrà accedere a determinate risorse all’insaputa dell’utente.
L’utente ha dunque un potere molto elevato e può contribuire in modo attivo alla costruzione della sicurezza del proprio dispositivo, scegliendo le applicazioni che ritiene utilizzino solamente le risorse coerenti con le funzionalità che l’applicazione dichiara.

Le Chambers d’altro canto sono una politica estremamente restrittiva ma che fornisce un meccanismo passivo di protezione, a volte anche macchinoso  per l’utente che non ha a disposizione direttamente la classica gerarchia ad albero di tutto il filesystem ma certamente adatto per sistemi mobili che contengono larghe fette della nostra vita, della vita di chi ci circonda e del nostro lavoro. Per il tipo di operatività di uno smartphone sono una scelta di progettazione azzeccatissima.

Security first! E ricordate che la sicurezza dei sistemi è una responsabilità civica. Sui vostri dispositivi sono presenti non solo dati che vi appartengono ma anche dati personali, foto e video dei vostri contatti ed è quindi vostra responsabilità proteggerli per tutelare non solo voi ma anche le persone con cui stringete rapporti. 🙂

Alla prossima, per spulciare ancora un po’ dietro le quinte di Windows Phone 8…

Advertisements

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...