Riprendendo il discorso del precedente articolo, continuiamo a parlare del meccanismo della sandbox, utilissima funzione che permette l’esecuzione delle app in un ambiente isolato per garantire la sicurezza; ne avevamo iniziato a discutere il funzionamento nel precedente articolo.
Il meccanismo sandbox è indubbiamente potente e molto avanzato rispetto a meccanismi simili in altri sistemi operativi. Tuttavia, non è infallibile. L’approccio della “lista nera” che blocca le operazioni pericolose note è efficace tanto quanto la lista è restrittiva. Ad esempio, nel novembre 2011 i ricercatori dei Core Labs hanno dimostrato che il profilo no-network di macOS Lion limitava effettivamente l’accesso alla rete, ma non limitava AppleEvents.
Cosa significa, in soldoni?
Semplicemente, un’app dannosa non accedeva ad internet perché bloccata dalla sandbox, ma, era tranquillamente in grado di attivare AppleScript e connettersi alla rete tramite un processo proxy non sandboxato.
La sandbox, quindi fu migliorata ancora a macOS Mountain Lion, dove fu rinominata GateKeeper che introdusse il famoso set di attributi estesi di relativi quarantena, responsabile della familiare finestra di avvertimento ‘Questa è un’applicazione scaricata da Internet’.
Con l’avvento di GateKeeper fu introdotto anche un nuovo comando a riga di comando, asctl, che consente una regolazione molto più delicata del meccanismo di protezione sandbox. Questa utility consente di avviare applicazioni e tracciare le attività che compiono in sandbox, costruendo un profilo personalizzato in base ai requisiti dell’app, a come si comporta. Consente inoltre di stabilire un “contenitore” per un’app, in particolare per quelle del Mac Store: questi contenitori sono delle semplici cartelle per le app, memorizzate nella percorso Library/Containers.
Le autorizzazioni che vengono concesse alle app, sono molto simili in termini di meccanismo a quelle utilizzate in Android, che costituiscono anche la base per la sicurezza di Dalvik. Queste autorizzazioni, diritti, non sono altro che una lista di proprietà.
L’architettura sandbox
FreeBSD è stato il primo ad introdurre una potente funzionalità di sicurezza nota come Mandatory Access Control (MAC). Questa funzione, che implementa un modello di sicurezza molto fine, migliora il modello Unix (piuttosto grezzo) limitando l’accesso a determinati file o risorse (come socket, IPC e così via) da processi specifici, non solo dalle autorizzazioni. In questo modo, ad esempio, una certa app potrebbe essere limitata in modo da non accedere ai dati privati dell’utente, a servizi o addirittura ad alcuni siti Web.
Pensate al concetto MAC come fosse un’etichetta: questa tecnologia nega l’accesso a qualsiasi oggetto non conforme all’etichetta; macOS estende ulteriormente queste politiche di sicurezza.
Dietro le quinte, chi si impegna per mantenere funzionante l’ambiente sandbox? Ovviamente il kernel, xnu! Il livello MAC di BSD (descritto sopra) è il meccanismo con il quale funzionano sia la sandbox che le autorizzazioni; l’estensione principale del kernel, responsabile della sandbox è sandbox.kext, comune sia a macOS che ad iOS. Una seconda estensione del kernel, unica per iOS, è AppleMobileFileIntegrity (la gloriosa quanto famosa AMFI) che applica le autorizzazioni e la firma del codice (ed è causa dell’incessante lavoro dei jailbreaker). Inoltre, la sandbox ha anche un demone dedicato, /usr/libexec/sandboxd, che viene eseguito in usermode (modalità utente) per fornire traccia dei servizi sandboxati e viene avviato su richiesta. Anche in iOS, esiste l’AMFI che ha anche il suo demone dedicato, /usr/libexec/amfid.
L’architettura della sandbox in macOS è la seguente:
Anche per questo articolo è tutto. Per eventuali domande, curiosità o feedback potete lasciare un commento qui in basso, a presto!