Sandbox : définition, principe d'isolation et système de fichiers

Qu'est-ce que la Sandbox

Sandbox est un système de contrôle d'accès obligatoire (Mandatory Access Control) implémenté au niveau du noyau d'iOS (XNU — extension de noyau Sandbox.kext). Chaque application reçoit au lancement un profil Sandbox UUID unique qui détermine les ressources auxquelles l'application est autorisée à accéder.

L'architecture de la Sandbox comprend trois composants clés : File System Isolation (chaque application ne voit que son propre conteneur), Network Access Control (les requêtes vers le réseau local peuvent être restreintes) et Inter-Process Communication (interdiction de l'IPC direct avec d'autres applications). Apple a introduit la Sandbox dans iOS 2.0 et a depuis considérablement renforcé les restrictions à chaque version majeure.

La Sandbox n'est pas optionnelle — toutes les applications de l'App Store fonctionnent dans le bac à sable. Le développeur ne peut ni désactiver la Sandbox ni contourner ses restrictions. Toute tentative d'accès à une ressource interdite se termine par le code d'erreur EPERM (Operation not permitted) et une entrée dans le journal système.

import Foundation

// Tentative d'accès au fichier d'une autre application — renvoie nil
let otherAppPath = "/var/mobile/Containers/Data/Application/OTHER-UUID/Documents/file.txt"
let data = try? Data(contentsOf: URL(fileURLWithPath: otherAppPath))
// data == nil — la Sandbox bloque l'accès

// Accès correct — dans sa propre Sandbox
let fileManager = FileManager.default
guard let documentsURL = fileManager.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first else { return }

let myFileURL = documentsURL.appendingPathComponent("notes.txt")
try "Hello, Sandbox!".write(to: myFileURL, atomically: true, encoding: .utf8)

Structure du bac à sable de l'application

La Sandbox de chaque application iOS contient plusieurs répertoires prédéfinis accessibles via l'API Foundation. L'emplacement sur le support physique est /var/mobile/Containers/Data/Application/{UUID}/, mais les développeurs ne doivent pas utiliser ce chemin directement : il change à chaque redémarrage de l'appareil dans les différentes versions d'iOS.

Les principaux répertoires de la Sandbox : Bundle (.app — lecture seule, contient le code exécutable et les ressources), Documents (données utilisateur, sauvegardées dans iCloud), Library (Caches, Preferences, Application Support — avec des règles de sauvegarde différentes), tmp (fichiers temporaires, supprimés par le système en cas de manque d'espace). Chaque répertoire a son propre cycle de vie et sa propre politique de stockage.

Le chemin physique de la Sandbox peut être obtenu via NSHomeDirectory() ou FileManager.url(for: .documentDirectory). Apple recommande l'API basée sur URL, car elle fait abstraction de la structure interne du système de fichiers et reste stable lors des changements de la Sandbox macOS sur le bureau.

Accès aux fichiers hors du bac à sable

L'accès direct au système de fichiers des autres applications est totalement bloqué dans iOS. Même si le développeur connaît l'UUID du conteneur d'une autre application, la Sandbox au niveau du noyau renvoie une erreur à toute tentative de lecture ou d'écriture. C'est une différence fondamentale entre iOS et macOS, où la Sandbox est plus flexible.

Apple propose trois mécanismes légitimes d'échange de données entre applications : UIDocumentPickerViewController (l'utilisateur sélectionne un fichier via l'interface système et l'application reçoit une URL Security-Scoped), Share Extension (une extension pour transmettre des données à une autre application) et App Groups (un répertoire partagé pour les applications du même développeur).

UIDocumentPicker est le seul moyen d'accéder aux fichiers d'autres applications sans configuration préalable. L'utilisateur sélectionne explicitement un fichier via le sélecteur système standard, et iOS fournit à l'application une URL Security-Scoped temporaire. L'accès dure jusqu'à la fermeture du sélecteur ou jusqu'à l'appel de stopAccessingSecurityScopedResource.

Security-Scoped Bookmarks

Un Security-Scoped Bookmark est un mécanisme d'iOS qui permet de conserver l'accès à un fichier hors de la Sandbox entre les lancements de l'application. Lorsque l'utilisateur sélectionne un fichier via UIDocumentPicker, l'application peut créer un bookmark à partir de l'URL Security-Scoped et le stocker dans UserDefaults ou dans un autre stockage.

Au lancement suivant, l'application restaure l'accès via URLByResolvingBookmarkData, qui renvoie une URL Security-Scoped. Ensuite, il faut appeler startAccessingSecurityScopedResource avant de lire le fichier et stopAccessingSecurityScopedResource après la fin du travail. L'équilibre des appels est obligatoire — chaque start doit avoir un stop correspondant, sinon le système épuise la limite des ressources Security-Scoped.

// Créer un Security-Scoped Bookmark
func createBookmark(for url: URL) -> Data? {
    return try? url.bookmarkData(
        options: .minimalBookmark,
        includingResourceValuesForKeys: nil,
        relativeTo: nil
    )
}

// Résoudre les données du bookmark en URL
func resolveBookmark(data: Data) -> URL? {
    var isStale = false
    let url = try? URL.byResolvingBookmarkData(
        data,
        options: .withoutUI,
        relativeTo: nil,
        bookmarkDataIsStale: &isStale
    )
    
    if isStale {
        // Le bookmark est obsolète, il faut en créer un nouveau
    }
    
    return url
}

Limitation importante : les Security-Scoped Bookmarks ne fonctionnent pas pour les fichiers situés dans sa propre Sandbox — uniquement pour les fichiers obtenus via UIDocumentPicker ou iCloud Drive. Un bookmark contient des données Security-Scoped qui permettent au système d'identifier quelle application demande l'accès à quel fichier. Si le certificat de l'application expire ou change, le bookmark devient invalide.

Sandbox et App Groups

App Groups est un mécanisme d'iOS qui permet à plusieurs applications (et leurs extensions) d'un même développeur de partager un répertoire Sandbox commun. Pour l'activer, il faut ajouter la Capability App Groups dans Xcode et indiquer le même identifiant de groupe pour toutes les applications cibles.

Le répertoire partagé des App Groups se trouve hors de la Sandbox de chaque application individuelle, mais toutes les applications du groupe y ont un accès complet en lecture et en écriture. Cela permet d'échanger des fichiers, des bases de données (Core Data avec le Store URL dans l'App Group) et des UserDefaults (via initWithSuiteName) entre l'application principale, le Today Widget, la Watch Extension et la Share Extension.

Apple recommande d'utiliser les App Groups pour la synchronisation d'état entre une application et ses extensions. Par exemple, le widget Today Widget peut lire les données du répertoire partagé des App Groups, où l'application principale écrit les données actualisées. En même temps, chaque application reste isolée des autres App Groups — seules les applications ayant le même identifiant de groupe y ont accès.

Limites du bac à sable dans iOS

La Sandbox dans iOS impose un certain nombre de restrictions strictes à prendre en compte lors du développement. Les principales : l'interdiction du code dynamique (chargement et exécution de code hors de la Sandbox), l'interdiction de l'accès direct au carnet d'adresses, au calendrier et aux photos sans l'autorisation de l'utilisateur (Privacy framework), et les restrictions sur la création de processus enfants (fork et exec sont interdits).

Réseau : les applications peuvent se connecter à tout serveur distant via TCP/UDP, mais l'accès à localhost est restreint — les autres applications ne peuvent pas se connecter à un serveur à l'intérieur de votre application (sauf dans les builds de débogage). L'UDP multicast et broadcast est également bloqué pour les applications de l'App Store.

Ressources matérielles : l'accès à la caméra, au microphone, à la géolocalisation, au Bluetooth et à HealthKit exige une autorisation explicite de l'utilisateur via la boîte de dialogue système. Pour chaque type de ressource, iOS utilise un entitlement distinct et une clé Info.plist avec la description du motif (NSPhotoLibraryUsageDescription, NSCameraUsageDescription). Demander l'autorisation sans description du motif dans Info.plist entraîne la fermeture de l'application.

• Code dynamique — interdit : JavaScriptCore pour JS dans WebView, mais pas de code machine arbitraire
• Processus enfants — fork, exec et system ne sont pas disponibles depuis la Sandbox
• Accès aux appareils — caméra, microphone et GPS nécessitent une boîte de dialogue système
• Réseau local — l'UDP multicast et broadcast est bloqué pour l'App Store
• Clés de chiffrement — Keychain est disponible, mais uniquement pour sa propre application (kSecAttrAccessGroup pour App Group)