App Sandbox nello sviluppo mobile — cos'è, meccanismo e principio di funzionamento

Cos'è App Sandbox?

App Sandbox è un meccanismo di sicurezza architetturale che isola ogni applicazione nel proprio ambiente di esecuzione con accesso limitato alle risorse di sistema. Il termine deriva dal concetto di sabbiera per bambini — uno spazio sicuro dove un bambino può giocare senza accedere a oggetti pericolosi. Allo stesso modo, un'applicazione viene eseguita in un ambiente ristretto senza accesso ai dati di altre applicazioni o ai componenti critici del sistema.

L'obiettivo principale di Sandbox è l'implementazione del principio del minimo privilegio: ogni applicazione riceve solo i diritti necessari per svolgere le funzioni dichiarate. Anche se un attaccante trova una vulnerabilità in un'applicazione, la sandbox impedisce l'accesso ai dati di altre applicazioni, foto, contatti o file di sistema. Il danno è limitato ai confini di una singola applicazione.

I sistemi operativi mobili hanno implementato le sandbox prima dei sistemi desktop. iOS utilizza Sandbox dalla prima versione dell'SDK (2008), Android dalla versione 1.0 (2008), con rafforzamento in Android 4.3 (2013) tramite SELinux. I sistemi desktop stanno recuperando: macOS ha introdotto Sandbox nel 2012, Windows ha introdotto le applicazioni UWP isolate in Windows 8.

Come funziona l'isolamento nella sandbox?

L'isolamento nella sandbox si ottiene attraverso una combinazione di diversi meccanismi a diversi livelli del sistema operativo. A livello del file system, a ogni applicazione viene allocata una propria directory protetta a cui solo essa ha accesso completo. A livello di processi, viene utilizzato un identificatore univoco di utente (UID) per ogni applicazione. A livello del kernel, viene applicato il controllo di accesso obbligatorio (MAC) tramite SELinux o meccanismi simili.

Isolamento del file system

Ogni applicazione riceve la propria directory radice sul file system del dispositivo. In iOS, questa è la directory /var/mobile/Containers/Data/Application/{UUID}, in Android — /data/data/{package_name}. L'applicazione può leggere e scrivere file solo all'interno di questa directory. L'accesso a qualsiasi file al di fuori di questa directory viene bloccato a livello del kernel del sistema operativo.

Il sistema fornisce anche directory condivise speciali con accesso limitato. In iOS, queste sono la directory Documents per i dati utente, Library per le impostazioni e Caches per i file temporanei. In Android — archiviazione interna (getFilesDir) e archiviazione esterna (getExternalFilesDir), il cui accesso non richiede autorizzazioni aggiuntive.

Isolamento dei processi e UID

In Android, ogni applicazione viene eseguita come un processo Linux separato con un UID univoco (User ID). L'UID viene assegnato all'installazione dell'applicazione e rimane invariato per tutto il suo ciclo di vita. I processi con UID diversi sono isolati tra loro a livello del kernel — non possono accedere alla memoria o ai file l'uno dell'altro. Un meccanismo simile funziona in iOS attraverso il kernel XNU e il suo sistema di protezione.

Un ulteriore livello di protezione in Android è fornito da SELinux (Security-Enhanced Linux) in modalità enforcing da Android 4.3. SELinux implementa il controllo di accesso obbligatorio (MAC): ogni azione del processo viene verificata rispetto alla politica di sicurezza indipendentemente dai permessi del proprietario del file. Anche se un'applicazione viene eseguita con UID root, SELinux può bloccare l'accesso a determinate risorse.

Sandbox in iOS

La sandbox di iOS è considerata una delle più rigorose tra i sistemi operativi mobili. Ogni applicazione è isolata a livello di contenitore — un'area protetta del file system a cui altre applicazioni non possono accedere. iOS utilizza una combinazione di controllo di accesso obbligatorio tramite Sandbox Kernel Extension (Sandbox.kext) e il meccanismo di entitlements per concedere privilegi estesi.

Struttura del contenitore iOS

Il contenitore di un'applicazione iOS è composto da diverse directory con diversi livelli di accesso. Documents — per i dati utente che vengono preservati durante il backup tramite iCloud e iTunes. Library — per i file di configurazione e cache. tmp — per i dati temporanei che il sistema può eliminare in qualsiasi momento. AppName.app — il bundle dell'applicazione stesso, che è in sola lettura.

L'accesso ai dati di altre applicazioni è severamente vietato. iOS non fornisce un'API per leggere file dal contenitore di un'altra applicazione. L'unico modo per condividere dati è attraverso meccanismi di sistema: UIActivityViewController per la condivisione, UIPasteboard per gli appunti, App Groups per le applicazioni dello stesso sviluppatore. Ciascuno di questi meccanismi opera sotto il controllo del sistema operativo.

Entitlements e App Sandbox in iOS

Capacità estese oltre la sandbox standard sono fornite tramite Entitlements — firme digitali aggiunte alla firma del codice dell'applicazione. Ad esempio, l'entitlement com.apple.security.application-groups permette alle applicazioni dello stesso gruppo di avere un contenitore condiviso. Notifiche push, iCloud, Apple Pay — tutte queste funzionalità richiedono entitlements corrispondenti.

È importante notare che gli entitlements in iOS non sono la stessa cosa delle autorizzazioni. Le autorizzazioni vengono richieste all'utente in fase di esecuzione (ad esempio, accesso alla fotocamera), mentre gli entitlements vengono verificati dal sistema al momento dell'installazione e non possono essere modificati dall'utente. Gli entitlements sono definiti dallo sviluppatore e firmati da Apple durante il processo di revisione dell'app.

Sandbox in Android

Android utilizza un modello di sandbox a più livelli basato sul kernel Linux. Ogni applicazione viene eseguita come un utente Linux separato con un UID univoco, fornendo un isolamento di base a livello di processi e file. I livelli aggiuntivi includono SELinux per il controllo di accesso obbligatorio e le Autorizzazioni per controllare l'accesso alle API di sistema.

SELinux e isolamento UID

SELinux in Android viene eseguito in modalità enforcing, il che significa l'applicazione forzata delle politiche di sicurezza. A ogni applicazione viene assegnato un contesto di sicurezza e tutte le chiamate di sistema vengono verificate rispetto alla politica. SELinux in Android contiene oltre 1500 regole che coprono il file system, la comunicazione tra processi, i socket e le chiamate di sistema.

L'isolamento UID impedisce a un'applicazione di accedere direttamente ai file di un'altra applicazione. Ad esempio, l'applicazione A con UID 10001 non può leggere i file dell'applicazione B con UID 10002, anche se entrambe vengono eseguite sotto lo stesso account utente del telefono. Questo è il principio di base della sicurezza multi-utente di Linux, adattato per i dispositivi mobili.

// Accesso alla directory propria dell'applicazione in Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// Tentare di accedere alla directory di un'altra applicazione causerà SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// Utilizzo di FileProvider per la condivisione sicura dei file
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Android fornisce meccanismi aggiuntivi per lo scambio sicuro di dati tra applicazioni. ContentProvider — un componente Android che permette a un'applicazione di fornire accesso ai propri dati ad altre applicazioni tramite un URI rigorosamente definito. FileProvider — un modo sicuro per condividere file senza rivelare i percorsi del file system.

Limitazioni e sicurezza della sandbox

Nonostante App Sandbox sia un potente meccanismo di sicurezza, ha limitazioni fondamentali. La sandbox protegge dall'accesso orizzontale (da applicazione ad applicazione), ma non dall'accesso verticale (malware a livello del kernel o accesso fisico al dispositivo). Con jailbreak o accesso root, la sandbox può essere aggirata poiché l'attaccante ottiene privilegi di superutente.

La seconda limitazione sono le autorizzazioni dannose. Se un utente concede a un'applicazione l'accesso ai contatti e al microfono, la sandbox non può impedire la raccolta di questi dati poiché l'applicazione utilizza API di sistema legittime. La protezione in questo caso passa al livello di consapevolezza dell'utente e ai processi di revisione di App Store e Google Play.

La terza limitazione è l'interazione tra sandbox. Alcuni servizi di sistema (NotificationListenerService, AccessibilityService) hanno accesso esteso ai dati di altre applicazioni. Un attaccante potrebbe utilizzare questi servizi per aggirare la sandbox se ottiene le autorizzazioni appropriate. Google e Apple aggiornano costantemente le politiche per tali servizi.

Nonostante le limitazioni, la sandbox è un componente di sicurezza critico dei sistemi operativi mobili. Secondo Android Security Report (2024), l'isolamento della sandbox previene più del 99% dei tentativi di accesso tra applicazioni. In combinazione con Code Signing, App Review e autorizzazioni in fase di esecuzione, Sandbox forma una protezione multilivello del moderno dispositivo mobile.