App Sandbox dans le développement mobile — qu'est-ce que c'est, mécanisme et principe de fonctionnement

Qu'est-ce que App Sandbox ?

App Sandbox est un mécanisme de sécurité architecturale qui isole chaque application dans son propre environnement d'exécution avec un accès limité aux ressources système. Le terme provient du concept de bac à sable pour enfants — un espace sécurisé où un enfant peut jouer sans accéder à des objets dangereux. De même, une application s'exécute dans un environnement restreint sans accès aux données d'autres applications ni aux composants critiques du système.

L'objectif principal de Sandbox est la mise en œuvre du principe du moindre privilège : chaque application reçoit uniquement les droits nécessaires à l'exécution de ses fonctions déclarées. Même si un attaquant trouve une vulnérabilité dans une application, la sandbox empêche l'accès aux données d'autres applications, aux photos, aux contacts ou aux fichiers système. Les dommages sont limités aux frontières d'une seule application.

Les systèmes d'exploitation mobiles ont implémenté les sandboxes avant les systèmes de bureau. iOS utilise Sandbox depuis la première version du SDK (2008), Android depuis la version 1.0 (2008), avec un renforcement dans Android 4.3 (2013) via SELinux. Les systèmes de bureau rattrapent leur retard : macOS a introduit Sandbox en 2012, Windows a introduit les applications UWP isolées dans Windows 8.

Comment fonctionne l'isolation dans la sandbox ?

L'isolation dans la sandbox est réalisée par une combinaison de plusieurs mécanismes à différents niveaux du système d'exploitation. Au niveau du système de fichiers, chaque application reçoit son propre répertoire protégé auquel elle seule a un accès complet. Au niveau des processus, un identifiant unique d'utilisateur (UID) est utilisé pour chaque application. Au niveau du noyau, un contrôle d'accès obligatoire (MAC) est appliqué via SELinux ou des mécanismes similaires.

Isolation du système de fichiers

Chaque application reçoit son propre répertoire racine sur le système de fichiers de l'appareil. Sous iOS, il s'agit du répertoire /var/mobile/Containers/Data/Application/{UUID}, sous Android — /data/data/{package_name}. L'application peut lire et écrire des fichiers uniquement dans ce répertoire. L'accès à tout fichier en dehors de ce répertoire est bloqué au niveau du noyau du système d'exploitation.

Le système fournit également des répertoires partagés spéciaux avec un accès limité. Sous iOS, ce sont le répertoire Documents pour les données utilisateur, Library pour les configurations et Caches pour les fichiers temporaires. Sous Android — le stockage interne (getFilesDir) et le stockage externe (getExternalFilesDir), dont l'accès ne nécessite pas d'autorisations supplémentaires.

Isolation des processus et des UID

Sous Android, chaque application s'exécute comme un processus Linux séparé avec un UID unique (User ID). L'UID est attribué lors de l'installation de l'application et reste inchangé tout au long de son cycle de vie. Les processus avec des UID différents sont isolés les uns des autres au niveau du noyau — ils ne peuvent pas accéder à la mémoire ou aux fichiers de l'autre. Un mécanisme similaire fonctionne sous iOS via le noyau XNU et son système de protection.

Une couche de protection supplémentaire sous Android est fournie par SELinux (Security-Enhanced Linux) en mode enforcing depuis Android 4.3. SELinux implémente un contrôle d'accès obligatoire (MAC) : chaque action du processus est vérifiée par rapport à la politique de sécurité indépendamment des droits du propriétaire du fichier. Même si une application s'exécute avec l'UID root, SELinux peut bloquer l'accès à certaines ressources.

Sandbox dans iOS

La sandbox iOS est considérée comme l'une des plus strictes parmi les systèmes d'exploitation mobiles. Chaque application est isolée au niveau du conteneur — une zone protégée du système de fichiers inaccessible aux autres applications. iOS utilise une combinaison de contrôle d'accès obligatoire via Sandbox Kernel Extension (Sandbox.kext) et du mécanisme d'entitlements pour accorder des privilèges étendus.

Structure du conteneur iOS

Le conteneur d'une application iOS se compose de plusieurs répertoires avec différents niveaux d'accès. Documents — pour les données utilisateur qui sont conservées lors de la sauvegarde via iCloud et iTunes. Library — pour les fichiers de configuration et de cache. tmp — pour les données temporaires que le système peut supprimer à tout moment. AppName.app — le bundle de l'application lui-même, qui est en lecture seule.

L'accès aux données d'autres applications est strictement interdit. iOS ne fournit pas d'API pour lire les fichiers du conteneur d'une autre application. La seule façon de partager des données est via des mécanismes système : UIActivityViewController pour le partage, UIPasteboard pour le presse-papiers, App Groups pour les applications d'un même développeur. Chacun de ces mécanismes fonctionne sous le contrôle du système d'exploitation.

Entitlements et App Sandbox dans iOS

Des capacités étendues au-delà de la sandbox standard sont fournies via les Entitlements — des signatures numériques ajoutées à la signature de code de l'application. Par exemple, l'entitlement com.apple.security.application-groups permet aux applications d'un même groupe d'avoir un conteneur partagé. Notifications push, iCloud, Apple Pay — toutes ces fonctionnalités nécessitent des entitlements correspondants.

Il est important de noter que les entitlements dans iOS ne sont pas la même chose que les autorisations. Les autorisations sont demandées à l'utilisateur au moment de l'exécution (par exemple, accès à la caméra), tandis que les entitlements sont vérifiés par le système lors de l'installation et ne peuvent pas être modifiés par l'utilisateur. Les entitlements sont définis par le développeur et signés par Apple lors du processus de révision de l'application.

Sandbox dans Android

Android utilise un modèle de sandbox multicouche basé sur le noyau Linux. Chaque application s'exécute comme un utilisateur Linux séparé avec un UID unique, ce qui offre une isolation de base au niveau des processus et des fichiers. Les couches supplémentaires incluent SELinux pour le contrôle d'accès obligatoire et les autorisations pour contrôler l'accès aux API système.

SELinux et isolation des UID

SELinux dans Android fonctionne en mode enforcing, ce qui signifie l'application forcée des politiques de sécurité. Chaque application se voit attribuer un contexte de sécurité, et tous les appels système sont vérifiés par rapport à la politique. SELinux dans Android contient plus de 1500 règles couvrant le système de fichiers, la communication interprocessus, les sockets et les appels système.

L'isolation des UID empêche une application d'accéder directement aux fichiers d'une autre application. Par exemple, l'application A avec UID 10001 ne peut pas lire les fichiers de l'application B avec UID 10002, même si les deux s'exécutent sous le même compte utilisateur du téléphone. C'est le principe de base de la sécurité multi-utilisateurs de Linux, adapté pour les appareils mobiles.

// Accès au propre répertoire de l'application dans Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// Tenter d'accéder au répertoire d'une autre application génère SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// Utilisation de FileProvider pour le partage sécurisé de fichiers
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Android fournit des mécanismes supplémentaires pour l'échange sécurisé de données entre applications. ContentProvider — un composant Android qui permet à une application de fournir l'accès à ses données à d'autres applications via un URI strictement défini. FileProvider — un moyen sécurisé de partager des fichiers sans révéler les chemins du système de fichiers.

Limitations et sécurité de la sandbox

Bien que App Sandbox soit un mécanisme de sécurité puissant, il a des limitations fondamentales. La sandbox protège contre l'accès horizontal (d'application à application), mais pas contre l'accès vertical (malware au niveau du noyau ou accès physique à l'appareil). En cas de jailbreak ou d'accès root, la sandbox peut être contournée car l'attaquant obtient les privilèges de superutilisateur.

La deuxième limitation est celle des autorisations malveillantes. Si un utilisateur accorde à une application l'accès aux contacts et au microphone, la sandbox ne peut pas empêcher la collecte de ces données car l'application utilise des API système légitimes. La protection dans ce cas passe au niveau de la sensibilisation de l'utilisateur et des processus de révision de l'App Store et de Google Play.

La troisième limitation est l'interaction entre sandboxes. Certains services système (NotificationListenerService, AccessibilityService) ont un accès étendu aux données d'autres applications. Un attaquant pourrait utiliser ces services pour contourner la sandbox s'il obtient les autorisations appropriées. Google et Apple mettent constamment à jour les politiques pour ces services.

Malgré les limitations, la sandbox est un composant de sécurité critique des systèmes d'exploitation mobiles. Selon Android Security Report (2024), l'isolation par sandbox empêche plus de 99% des tentatives d'accès inter-applications. En combinaison avec la signature de code, l'examen des applications et les autorisations au moment de l'exécution, Sandbox forme une protection multicouche de l'appareil mobile moderne.