Qu'est-ce que iOS App Sandboxing?

iOS app sandboxing est une architecture de sécurité de base qui limite chaque application à son propre conteneur dédié, l'empêchant d'accéder aux fichiers système, autres données de l'application ou ressources matérielles sans le consentement explicite de l'utilisateur. Lorsqu'une application est installée, le système d'exploitation crée un répertoire unique de sandbox pour cette application, et tous ses codes, données, préférences et caches vivent à l'intérieur de ce répertoire. L'application ne peut échapper à son conteneur pour lire ou écrire des fichiers appartenant à une autre application ou au système lui-même.

Le modèle sandbox est appliqué au niveau du noyau, ce qui signifie qu'il s'applique à toutes les applications, y compris celles distribuées par l'App Store, les déploiements d'entreprise et même les applications système. Le système d'exploitation agit sur chaque système de fichiers, connexion réseau et appel matériel, permettant uniquement les actions qui entrent dans les droits accordés par l'application.

L'architecture technique derrière le bac à sable

Au niveau du noyau, iOS utilise des contrôles d'accès obligatoires (MAC) appliqués par le cadre de la Seatbelt sandbox. Seatbelt définit un ensemble de règles pour chaque processus d'application, précisant les fichiers, répertoires, terminaux réseau et services système auxquels le processus peut accéder. Ces règles sont compilées dans un profil sandbox qui est chargé lors du lancement de l'application. Le profil est unique à chaque application et ne peut pas être dépassé par l'application elle-même.

Chaque application obtient son propre répertoire de conteneurs, généralement situé à . Dans ce conteneur, le système divise le stockage en sous-répertoires tels que , et . L'application peut lire et écrire librement à l'intérieur de son propre conteneur, mais toute tentative d'accès à des chemins extérieurs à ce conteneur déclenche un déni du noyau.

Les profils Sandbox limitent également la communication interprocessus (IPC). Les applications ne peuvent pas appeler des services système arbitraires ou lancer des processus de fond sans droits spécifiques. Cela signifie que même si une application parvient à exécuter un code arbitraire, elle ne peut pas, par exemple, lancer un démon qui fonctionne de façon persistante dans l'arrière-plan ou envoyer des messages au processus d'une autre application.

Mesures de sécurité de base dans iOS

Le sandboxing ne fonctionne pas isolément. Il fait partie d'un modèle de sécurité stratifié qui comprend plusieurs mesures complémentaires conçues pour protéger les données utilisateur et l'intégrité du système à tous les niveaux.

Autorisations d'application et contrôle de l'utilisateur

iOS exige que les applications demandent l'autorisation avant d'accéder à des données ou du matériel sensibles. Cela inclut la caméra, le microphone, les services de localisation, la bibliothèque de photos, les contacts, le calendrier, Bluetooth et les capteurs de mouvement. Les autorisations sont accordées par une invitation à l'exécution qui apparaît la première fois que l'application tente d'accéder à la ressource.

Par exemple, iOS 14 a ajouté un partage approximatif de l'emplacement et la possibilité d'accorder un accès photo par image. iOS 15 a introduit App Privacy Report, qui enregistre les ressources auxquelles chaque application a accès. iOS 16 et 17 a encore affiné les notifications d'accès au presse-papiers, les appels d'autorisation de collage et le mode de verrouillage pour les utilisateurs à haut risque. Ces mécanismes garantissent que même si une application est bénigne, les utilisateurs conservent un contrôle granulaire sur les données partagées.

Signature de code et validation de l'application

Chaque application qui fonctionne sur iOS doit être signée numériquement par Apple en utilisant un certificat délivré au développeur. Ce processus, appelé signature de code, garantit que le code n'a pas été altéré depuis qu'il a été signé. Lorsque le système charge une application, il vérifie la signature contre l'infrastructure de clé publique d'Apple. Si la signature est invalide, manquante ou expirée, l'application ne démarrera pas.

La signature de code s'étend au-delà de l'installation de l'application. Le système vérifie également les signatures de code à l'exécution pour les bibliothèques et les cadres chargés dynamiquement. Cela empêche une application de charger du code non signé après le lancement, qui est une technique courante utilisée par les logiciels malveillants pour contourner les vérifications initiales.

Chiffrement des données au repos et en transit

Les appareils iOS utilisent le cryptage soutenu par le matériel pour protéger les données stockées sur le stockage flash. Chaque appareil dispose d'un moteur AES dédié intégré au système sur puce, qui chiffre et déchiffre les données à l'aide d'une clé spécifique à l'appareil. Le système applique différentes classes de cryptage à différents types de données:

  • Classe A (Protection complète):[ Les données sont cryptées avec une clé dérivée du code d'accès de l'utilisateur et ne sont accessibles que lorsque l'appareil est déverrouillé.
  • Classe B (Protected Jusqu'à la première déverrouillage): Les données deviennent accessibles après le premier déverrouillage et restent accessibles jusqu'à ce que l'appareil soit redémarré.
  • Classe C (Protected A moins qu'Open): Les données sont accessibles tant que le fichier est ouvert, même si l'appareil est verrouillé.
  • Classe D (No Protection): Les données sont cryptées mais la clé est toujours disponible après le démarrage.

En plus du chiffrement au repos, iOS impose la sécurité de Transport Layer (TLS) pour toutes les connexions réseau effectuées par les services système et de nombreuses applications. Apple exige que les applications utilisent HTTPS par défaut et a supprimé les exceptions de l'application Transport Security (ATS) au fil du temps. Cela garantit que les données transmises entre l'appareil et les serveurs sont cryptées en transit, ce qui rend difficile pour les attaquants d'intercepter ou de modifier le trafic.

Chaîne de démarrage sécurisée et racines matérielles de confiance

Lorsqu'un appareil iOS est activé, il exécute le code d'un boot ROM en lecture seule qui est gravé dans la puce pendant la fabrication. Ce boot ROM est immuable et est la racine matérielle de la confiance. Il vérifie la signature du chargeur de démarrage de la prochaine étape (iBoot) à l'aide de la clé publique d'Apple. iBoot vérifie ensuite le noyau, et le noyau vérifie le système d'exploitation et toutes les extensions du système.

Si un composant échoue à la vérification de signature, le processus de démarrage s'arrête et l'appareil entre en mode de récupération. Cette chaîne de confiance garantit que seul le logiciel Apple autorisé peut fonctionner sur l'appareil, dès la première instruction. Il empêche les logiciels malveillants de persister sur les reboots et rend la jailbreaking de plus en plus difficile avec chaque génération de matériel.

Comment le bac à sable empêche les vecteurs d'attaque communs

Comprendre l'impact pratique du bac à sable aide à clarifier pourquoi iOS est considéré comme une plateforme sécurisée. Sandboxing bloque activement plusieurs techniques d'attaque communes:

  • Exfiltration de données entre les applications: Sans sandboxing, une application compromise pourrait lire les fichiers de chaque autre application sur l'appareil. Sandboxing empêche cela en s'assurant que chaque application a son propre système de fichiers isolé.
  • Modification du fichier système:[ Le code malveillant ne peut pas écraser les binaires, les bibliothèques ou les fichiers de configuration du système parce que ces fichiers résident à l'extérieur du conteneur de l'application.
  • Accès à la chaîne de clés: iOS fournit une chaîne de clés sécurisée pour stocker des jetons sensibles et des mots de passe. Chaque application ne peut accéder qu'à ses propres éléments Keychain, et le système l'applique au niveau du noyau.
  • Injure de processus de fond: Les applications ne peuvent pas créer de démons ou d'agents de fond sans droits explicites, qui sont rarement accordés.
  • Ressource de logiciels malveillants détournement:[ Même si une application obtient accès à la caméra ou au microphone par l'intermédiaire des instructions de permission, le sandboxing l'empêche d'accéder à d'autres matériels comme le contrôleur NFC ou l'Enclave sécurisée sans droits séparés.

Ces protections signifient que même les exploits de zéro clic — qui ne nécessitent aucune interaction avec l'utilisateur — sont fortement limités dans ce qu'ils peuvent atteindre. Un attaquant qui exploite avec succès une vulnérabilité dans une application sandboxed doit encore faire face au défi d'échapper à la sandbox pour obtenir une persistance significative ou un accès aux données.

Conséquences pour les développeurs

Pour les développeurs iOS, le sandboxing impose des contraintes qui façonnent la façon dont les applications sont conçues et testées. Chaque application doit déclarer les droits et les capacités dont elle a besoin, et Apple examine ces déclarations pendant le processus d'approbation de l'App Store.

Les principales conséquences pour le développement sont les suivantes :

  • Accès au système de fichiers:[ Les développeurs ne peuvent pas supposer qu'ils peuvent écrire dans des répertoires arbitraires. Tout le contenu généré par l'utilisateur doit être stocké dans le répertoire de l'application, et les fichiers temporaires doivent entrer dans .
  • Communication inter-applications:[ Le partage de données entre applications nécessite des mécanismes explicites comme UIActivityViewController, UIPasteboard ou des groupes d'accès partagés Keychain, qui nécessitent tous une configuration et une interaction utilisateur.
  • Exécution de fond:[ Les applications ne peuvent fonctionner en arrière-plan que pour des cas d'utilisation spécifiques, tels que la lecture audio, les mises à jour de localisation ou la récupération de fond.
  • Gestion des éléments:[ Les capacités comme les notifications push, Apple Pay et le stockage iCloud nécessitent des droits de profil de provisionnement. Les développeurs doivent configurer ces derniers dans le portail Apple Developer et s'assurer qu'ils correspondent au profil sandbox.
  • Les développeurs doivent tester leurs applications sur des appareils physiques pour vérifier la conformité des bacs à sable, car le simulateur a des règles de bac à sable détendues qui ne reflètent pas le comportement réel des appareils.

Apple fournit une documentation et des outils complets pour aider les développeurs à travailler dans les limites de la sandbox. Xcode comprend des fonctionnalités de débogage de la sandbox qui log violation d'accès, et le App Sandbox guide décrit les meilleures pratiques pour concevoir des applications sécurisées et conformes à la sandbox.

Incidences pour les utilisateurs

Pour les utilisateurs quotidiens, le sandboxing fonctionne silencieusement en arrière-plan, mais il peut aider à prendre des décisions éclairées sur les permissions d'application et le comportement de l'appareil. Lorsqu'une application demande l'accès à la caméra, au microphone ou à l'emplacement, les utilisateurs doivent examiner si la demande a un sens pour la fonctionnalité de l'application.

Les utilisateurs doivent également savoir que jailbreaking supprime les protections sandbox en désactivant l'application au niveau du noyau. Un appareil jailbroken n'isole plus les applications les unes des autres ou du système, ce qui le rend vulnérable aux logiciels malveillants qui pourraient voler des données, installer des logiciels espions ou causer une instabilité persistante du système. Apple décourage fortement le jailbreaking, et l'entreprise a rendu la tâche de plus en plus difficile avec chaque version iOS en durcissant la chaîne de démarrage sécurisée et en ajoutant des protections d'intégrité du noyau.

Les meilleures pratiques pour les utilisateurs sont les suivantes :

  • Consultez régulièrement les autorisations d'application dans Paramètres > Privacy & Security.
  • N'accordez que les autorisations nécessaires à la fonction principale de l'application.
  • Gardez iOS à jour pour recevoir les dernières améliorations de sécurité et de bac à sable.
  • Évitez de charger des applications de sources non fiables, car celles-ci peuvent contourner la signature de code d'Apple et l'examen de sécurité.
  • Activer Face ID ou Touch ID pour protéger les clés de chiffrement qui protègent les données sandboxed.

L'évolution de la sécurité iOS

Apple a continuellement renforcé les mesures de sandboxing et de sécurité depuis iOS a introduit le modèle avec iPhone OS 2.0. Les profils de sandbox étaient relativement simples et permettaient plus de flexibilité, mais à mesure que iOS a mûri, les profils sont devenus plus restrictifs et granulaires. L'introduction du système Les droits ont donné aux développeurs un moyen de demander des capacités spécifiques tout en gardant la sandbox par défaut aussi serrée que possible.

Les principales étapes sont les suivantes :

  • iOS 6: Introduit VPN par application et des classes de protection des données améliorées.
  • iOS 9: Active la sécurité du transport des applications par défaut, forçant les applications à utiliser HTTPS.
  • iOS 12: Ajout de plus strictes boîtes de sable pour le contenu Web Safari et introduction de mode limité USB.
  • iOS 14: Requiert toutes les applications pour demander la permission de suivre les utilisateurs sur les applications et les sites Web (App Tracking Transparency).
  • iOS 16: Introduit le mode de verrouillage pour les utilisateurs confrontés à des menaces sophistiquées, limitant fortement la surface d'attaque.
  • iOS 17: Mode de verrouillage élargi et ajout de fonctions de sécurité de suivi de liaison et de communication améliorées.

Chaque itération ferme les vecteurs d'attaque découverts par des chercheurs en sécurité ou exploités dans la nature. Apple maintient également un programme de primes de bug qui récompense les chercheurs pour trouver des vulnérabilités, y compris des échappés de bac à sable. Cette boucle de rétroaction aide Apple à identifier les faiblesses et à les corriger avant qu'ils puissent être largement exploités.

Conclusion

Le sandboxing de l'application iOS est un mécanisme de sécurité fondamental qui isole chaque application dans son propre conteneur, empêchant l'accès non autorisé aux ressources du système et à d'autres données de l'application. Combiné à la signature de code, au chiffrement des données, à la chaîne de démarrage sécurisée et aux autorisations des utilisateurs granulaires, il crée une défense en couches qui rend iOS l'une des plates-formes mobiles les plus sécurisées disponibles.

Pour en savoir plus sur l'architecture de sécurité iOS, consultez le iOS Security Guide et le Secure Coding Guide[.