Avec OS X Lion, Apple a introduit de nombreuses nouveautés pour les utilisateurs, mais aussi pour les développeurs. L'une d'entre elles est le sandboxing des applications, obligatoire à terme pour les applications distribuées par le biais du Mac App Store. Qu'est-ce que le sandboxing ? Que change-t-il pour les utilisateurs ? Et surtout, que change-t-il pour les développeurs ?
Un bac à sable avec des murs de douze mètres de haut
Il est traditionnellement possible, pour une application, d'avoir accès à l'intégralité des données et des fonctions logicielles et matérielles à disposition. Cette logique, qui met le système d'exploitation sur le devant de la scène, a permis le développement de nombreux utilitaires système, de pilotes, et de la plupart des fonctions avancées des applications. Dans ce cas, une application est libre d'aller et venir sur son terrain de jeu, et d'y faire ce qu'elle veut.
Le sandboxing est une pratique héritée d'iOS, qui met l'accent sur l'utilisation d'applications, le système d'exploitation devenant — pour très grossièrement résumer — un ensemble de services. Pour l'application placée en sandbox, rien n'existe d'autre que ce que le système lui permet de voir (certains fichiers explicitement requis, placés dans un dossier « virtuel » au sein du bac à sable) et d'utiliser (un jeu d'API réduit), le tout étant contrôlé par un système de signatures fournies par Apple. Le système peut, s'il en a besoin, supprimer les données de l'application. Dans ce cas, le terrain de jeu est constitué de multiples bacs à sable dotés de murs de douze mètres de haut, contenant chacun une application ne pouvant s'en échapper, le système l'alimentant avec des pipettes de juste ce qu'il faut pour être utilisable — ou s'amusant à piétiner son château de sable si besoin.
Cette logique a fait le succès d'iOS, selon le double argument sécuritaire et pratique. L'argument sécuritaire peut être facilement compris : dans son bac à sable, l'application ne peut compromettre la sécurité du système ou des autres applications en exécutant du code arbitraire ou en accédant directement aux fonctions matérielles. Le système lui fournit uniquement ce qu'il lui faut, et l'application ne peut sortir de son cadre. L'argument pratique est celui de l'optimisation et de la cohérence de l'environnement logiciel : toutes les applications ont accès au même jeu de services fournis par Apple, aux mêmes méthodes.
L'enjeu sécuritaire se retrouve sur OS X : en théorie, le sandboxing limite très fortement les risques de sécurité. Apple montre l'exemple avec trois applications système utilisant le bac à sable : Safari, Mail et Aperçu. Trois applications qui sont le plus souvent sources de problèmes par le biais de failles diverses, notamment dans la gestion des fichiers PDF et TIFF, failles que le sandboxing rend inopérantes en les confinant à l'espace réduit de l'application, isolé du reste du système. Le sandboxing étant contrôlé par un système de signatures fournies par Apple, le système peut à tout moment vérifier la validité d'une app : un malware a modifié une application, et sa signature n'est donc plus valide ? OS X refusera de l'exécuter.
Parce que ce système renforce la sécurité toute relative d'OS X, Apple a décidé de le rendre obligatoire pour toute application distribuée dans le Mac App Store d'ici mars 2012. Les développeurs vont donc devoir choisir entre la flexibilité et la présence dans le Mac App Store.
Sécurité ou flexibilité, il faut choisir
Avec le sandboxing, Apple oblige en effet les développeurs à se cantonner aux API fournies par OS X, et à préciser exactement quels sont les besoins de leurs applications pour obtenir des « permissions » d'usage. Ces permissions (
com.apple.security.xxx), appelées « entitlements » en anglais, sont en nombre limité — 19, seulement, contrôlées par un démon : - accès en lecture seule au dossier Vidéos et aux vidéos iTunes ;
- accès en lecture / écriture au dossier Vidéo et aux vidéos iTunes ;
- accès en lecture seule au dossier Musique ;
- accès en lecture / écriture au dossier Musique ;
- accès en lecture seule au dossier Images ;
- accès en lecture / écriture au dossier Images ;
- accès en lecture / écriture au dossier Téléchargements ;
- accès en lecture seule aux fichiers que l'utilisateur a explicitement sélectionné avec le dialogue Ouvrir ou Enregistrer ;
- accès en lecture / écriture aux fichiers que l'utilisateur a explicitement sélectionné avec le dialogue Ouvrir ou Enregistrer ;
- accès en lecture / écriture au carnet d'adresses de l'utilisateur ;
- accès en lecture / écriture aux calendriers de l'utilisateur ;
- capture vidéo et photo avec la webcam intégrée, si disponible ;
- enregistrement audio avec le microphone intégré, si disponible ;
- interaction avec les appareils USB ;
- transmission du sandboxing à un processus enfant par son parent ;
- ouverture et maintien d'une connexion sortante pour se connecter à d'autres machines ;
- ouverture et maintien d'une connexion entrante pour écouter les requêtes d'autres machines ;
- utiliser Core Location pour déterminer la position de l'ordinateur ;
- imprimer.
Il faut savoir raison garder : avec toutes les technologies et API mises à disposition par Apple et ces permissions, il est possible de réaliser des applications très avancées et très utiles. Certes, Apple demandera de parfaitement justifier les permissions demandées, mais elle pourra accorder ponctuellement un accès à certaines ressources (notamment les Apple Events), du moins de manière temporaire. Mais tout un pan des applications utilitaires est de fait exclu :
- puisqu'il est impossible d'aller plus loin que le système dans la gestion des périphériques Bluetooth, FireWire ou Thunderbolt, de nombreux utilitaires ne pourront pas être dans le Mac App Store ;
- puisqu'il est tout aussi impossible d'accéder à un service démarré par une application ou d'interagir avec les fonctions d'une application, les contrôleurs iTunes, les systèmes de communication entre applications ou les surcouches système (comme TextExpander) ne pourront pas non plus être dans la boutique d'Apple ;
- comme il est impossible d'accéder au système de fichiers complet, les clients FTP ou les logiciels de sauvegarde vont devoir soit sortir du Mac App Store, soit considérablement compliquer leur fonctionnement, pour demander l'accord de l'utilisateur à chaque étape ;
- enfin, puisque tout ce qui pourrait être assimilé à de l'exécution de code arbitraire est désormais inacceptable, de nombreuses applications ne seront plus accessibles par le biais d'AppleScript, les plug-ins vont être remis en cause, et tous les utilitaires étendant leurs fonctions par le biais de petits fichiers d'extensions devront trouver une autre solution.
Sécurité contre flexibilité, le choix est clair, et il pose certains problèmes. Plusieurs développeurs ont déjà fait état de leurs doutes quant à leur maintien dans le Mac App Store (lire : Sandboxing OS X : deux expériences de développeurs). Mais cela pose-t-il réellement problème aux développeurs d'utilitaires utilisés par une minorité bien renseignée ou aux gros studios qui ne veulent pas concéder 30 % à Apple ? Rien n'est moins sûr, et les applications types du Mac App Store sont celles qui devraient avoir le moins de mal à adopter le sandboxing. On retrouve là le problème classique des transitions technologiques (Carbon > Cocoa, PPC > Intel, etc.), qui nécessitent de réapprendre certains réflexes et de découvrir de nouveaux moyens pour faire certaines choses.
On peut néanmoins reprocher à Apple une certaine légèreté dans sa communication sur le sujet : certes elle accompagne les développeurs, mais le simple fait qu'elle ait elle-même repoussé la date limite d'adoption du sandboxing d'octobre 2011 à mars 2012 met la puce à l'oreille. La firme de Cupertino elle-même n'est pas prête. Le bogue de Safari avec les polices était un problème avec le bac à sable (lire : Lion bloque les gestionnaires de police avec Webkit), un système suffisamment compliqué à mettre en place pour qu'Apple se donne du temps supplémentaire pour le fignoler.
Les limites du sandboxing
Le sandboxing, de par sa nature, nécessite une grande attention de la part d'Apple : la moindre faille pourrait être exploitée et provoquer des dégâts considérables. Apple n'aurait alors le choix que de mettre à jour OS X, le plus rapidement possible de préférence. Et comme le rappelle Wil Shipley, le développeur de Delicious Library, « le code parfait » n'existe pas, surtout sur un OS qui a « autant d'instructions qu'en aurait le cerveau humain », selon le mot de Bertrand Serlet. Apple explique qu'elle vérifiera précautionneusement toutes les applications et les permissions demandées, mais la validation App Store a déjà montré ses faiblesses, un autre problème.
Une application malintentionnée pourrait donc demander peu de permissions pour passer les mailles du filet sans se faire remarquer, et ensuite exploiter une brèche, ou se retrouver face à une porte grande ouverte, ou même se passer de permissions pour faire certaines choses. Les équipes de validation App Store ont beau vérifier les applications, elles ne sont en rien parfaites : Charlie Miller a encore récemment réussi à soumettre une application iOS capable de télécharger du code distant pour l'exécuter en local. Cette application fait alors deux choses : exploiter toutes les permissions pour récupérer un maximum de données (photos, contacts, etc.), et détourner des fonctions de l'OS à son profit (lire : Une faille qui prend complètement à défaut le système de validation de l'App Store). Une telle malice serait tout aussi possible sur OS X Lion : il suffit de s'agripper à toutes les petites aspérités des murs construits autour des applications par Apple.
Bref, si le sandboxing va mécaniquement augmenter la sécurité sous OS X, par sa simple adoption forcée par les développeurs, il n'est en rien une solution miracle. Aucune solution, d'ailleurs, ne peut se prétendre miraculeuse, le sanboxing peut être contourné, les certificats peuvent être détournés (lire : OS X Lion et le problème des certificats TLS/SSL), la vérification de code n'est jamais suffisante. L'ensemble de ces solutions permet cependant d'améliorer globalement la sécurité, au prix de quelques ajustements pour les développeurs — et c'est ce qui compte aux yeux d'Apple.
Au-delà, la stratégie est claire : OS X se rapproche toujours plus d'iOS. En plus d'uniformiser les méthodes de développement et d'améliorer la sécurité, le sandboxing, facilite aussi la sauvegarde et la désinstallation des apps. Un point crucial sur iOS, et qui est en train de le devenir sur OS X avec le Launchpad, la tombée en désuétude du Finder, la gestion des fichiers via les apps et l'intégration d'iCloud. Le mot « application », né sur Mac par opposition au « programme » pour désigner des logiciels monotâches et spécialisés, est d'ailleurs la clef pour comprendre l'évolution d'OS X via iOS. Le système est une immense machinerie de moins en moins visible et de plus en plus transparente, qui n'est plus une plateforme que l'on peut bidouiller, mais un moteur pour de multiples applications. Un mouvement qui semble désormais inéluctable.
