Sandbox: come sono protette le app in macOS e iOS? #1

Dopo aver terminato di parlare della sicurezza di macOS, oggi parliamo di una caratteristica all’avanguardia e fiore all’occhiello delle app in macOS e iOS: il compartimentazione delle app e sandbox: iniziamo dal principio.

Preambolo

Cos’è la compartimentazione e perché è diventata parte integrante nel panorama dalle app?

L’idea si basa su un principio semplice, che riguarda la sicurezza delle app: semplicemente, quelle non attendibili devono essere eseguite in un compartimento isolato, come se l’esecuzione fosse spostata in un ambiente di “quarantena” nel quale tutte le operazioni sono soggette a restrizioni. Precedentemente, in macOS Leopard questa tecnica veniva chiamata seatbelt, rinominata ai giorni nostri a sandbox.

La sandbox in iOS

In iOS, la sandbox è stata integrata fin dal principio, dalla primissima versione ed è stata ulteriormente migliorata per creare il quel “carcere” che i jailbreaker faticano a rompere per ottenere i privilegi di amministrazione sul sistema. Quali sono le limitazioni imposte da questo “carcere” creato dalla sandbox?

Impossibilità di uscire dalla directory dell’app. L’app vede effettivamente la propria directory (/var/mobile/Applications/<app-GUID>) come root, simile alla chiamata di sistema chroot(2), ne avevamo già parlato qui. Come corollario: l’app non non sa quali altre applicazioni sono installate ed inoltre non può accedere ai file di sistema.
Impossibilità di accedere a qualsiasi altro processo sul sistema, anche se tale processo è di proprietà dello stesso UID. Per sintetizzare è come se l’app si considerasse come l’unico processo in esecuzione sul sistema.
Impossibilità di utilizzare direttamente qualsiasi dispositivo hardware esterno senza passare attraverso i framework di Apple (che, a loro volta, possono imporre delle limitazioni).
Impossibilità di generare dinamicamente del codice. Le implementazioni di basso livello delle chiamate di sistema mmap e mprotect sono intenzionalmente modificate per aggirare qualsiasi tentativo di rendere eseguibili delle pagine di memoria scrivibili, ma discuteremo di questi approcci in articoli futuri, prendeteli come ‘buoni’ per adesso.
Impossibilità di eseguire qualsiasi operazione, tranne di un insieme: quelle consentite per l’utente mobile. Le autorizzazioni di root per un’app sono praticamente sconosciute.

La prigione volontaria

Come accennato, l’esecuzione in un ambiente di sandbox è volontario (almeno in macOS). Un processo, per entrare in sandbox, deve chiamare il comando sandbox_ init, con un certo profilo, ad esempio:

no-internet: niente connessione ad internet
no-write: divieto di effettuare scritture sul file system

Una volta che il processo ha chiamato la funzione sandbox_init, a sua volta, chiama la syscall mac_execve che attraverso il profilo scelto, impone una serie di restrizioni sul processo; un qualsiasi tentativo di aggirare queste restrizioni si traduce in un errore a livello di chiamata di sistema (di solito un codice di ritorno di -EPERM). La (ex) seatbelt potremmo efficacemente rinominarla “sabbie mobili“, perché una volta inserita in sandbox, non c’è più via d’uscita.

Il vantaggio di una sandbox così stringente riguardo il fatto che un utente può eseguire un’applicazione non sicura in un ambiente chiuso senza temere che ad esempio un malware nascosto in un app, riesca a fare operazioni insidiose o semplicemente pericolose. I profili predefiniti (come i due visti sopra) servono solo come punto di partenza, perchè possono essere creati e personalizzati ad hoc per ogni singola applicazione.

Questi profili personalizzati sono dei file particolari con estensione .sb, che specificano quali azioni sono consentite e quali devono essere negate; questi profili vengono quindi compilati al momento del caricamento dalla libreria libSandbox.dylib.
Potete trovare molti esempi di questi file in /usr/share/sandbox e in /System/Library/Sandbox/Profiles.

Vi lascio inoltre con un’immagine molto esplicativa, presa dalla documentazione di Apple.