OS X Lion : comprendre le casse-tête du sandboxing

Anthony Nelzin-Santos |
sanboxing

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.

sandboxing

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.
avatar Nyx0uf | 
Tst test.
avatar Nemesys | 
Mon commentaire en tant que développeur. Peut-être que pour la majorité des utilisateurs, le "sandboxing" est une bonne chose mais pour les utilisateurs plus chevronnés, je prévoit quelques grincements de dents. Je distribue un logiciel de synchronisation sur le App Store. Depuis que mon logiciel y est, je réalise au moins 5 fois les ventes que j'effectuais personnellement. Alors, pour moi, il est clair que le App Store est important. Par contre, avec les permissions offertes par Apple pour utiliser les ressources, je vais devoir modifier mon logiciel pour qu'à chaque fois que l'utilisateur décide d'effectuer une synchronisation, je présente à 2 reprises un dialogue d'ouverture de fichiers et demande à l'utilisateur de confirmer le choix des 2 dossiers à synchroniser, en assumant que la sélection d'un dossier me permettra d'y accéder le contenu. Est-ce que l'utilisateur est gagnant dans cette situation ? J'en doute fortement. Peut-être que la synchronisation de fichiers n'est pas une activité prisée par tous les utilisateurs mais j'effectue près de 1000 ventes par mois, alors il y a clairement un besoin...
avatar ppj505 | 
Si le mécanisme est débrayable avec des fenêtres de notifications demandant si on autorise l'application à aller à tel endroit du système, pourquoi pas. Mais si on se rapproche un peu trop d'IOS avec, à terme (mais je ne pense pas que ce soit l'objectif d'Apple, mais sait on jamais ...), un accès direct impossible aux fichiers et surtout des ponts entre application rendus très difficiles, alors là je dis non !!! Si je prend l'exemple d'un mail à envoyer avec plusieurs pièces jointes de différents formats (du PDF, des photos, un fichier texte, ...), avec iOS il faut déjà les regrouper au sein d'une même application qui sait toutes les ouvrir : déjà pas simple à réaliser, car le plus souvent il faut d'abord les envoyer dans le nuage ou dans un mail, et les récupérer ensuite avec le soft concerné. Ca oblige à une prise de tête pour quelque chose qui était si simple, logique et intuitif. (j'utilise un iPad depuis seulement 2 mois, merci de me dire s'il y a plus simple !!) Si le rapprochement de OSX avec iOS peut être intéressant, il faudrait aussi aller dans l'autre sens et retrouver une mode de fonctionnement plus pratique avec iOS pour certaines tâches.
avatar ppj505 | 
j'ajoute seulement que j'ai bien conscience que débrayer le mécanisme tel que je le décris serait ridicule car totalement à l'encontre de l'objectif recherché, à savoir la sécurité, (cela ouvrirait grand la porte aux virus), mais c'est surtout histoire de poser la réflexion, soucieux, comme beaucoup sur cette discussion, du devenir de Mac OSX, pardon OSX.
avatar Jimmy_ | 
"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" D'où sort cette vérité révélée pour restreindre ceux qui ont envie de le faire ?
avatar Cflo22 | 
Excellent article une fois encore.
avatar yoa | 
Même si le sanboxing est clairement la solution d'avenir, l'implémentation stricte d'Apple est assez inquiétante. L'informatique se dirige vers un système aseptisé où l'utilisateur n'est plus qu'un consommateur cloisonné dans l'écosystème de l'éditeur. Pour votre culture générale, Android utilise également un sandoxing des applications très poussé, c'est une des raisons pour laquelle, comme sur iOS, les virus n'existent pas. Cependant, l'ouverture du SDK Android offre beaucoup plus de possibilité aux développeurs (et donc aux utilisateurs) que le SDK d'iOS. En contre partie, cela expose effectivement l'utilisateur à d'avantage d'applications malveillantes. Donc, la perte de flexibilité des applications Mac ne sera pas liée au sandboxing mais à la volonté d'Apple.
avatar Fingah | 
euh enfin on peut toujours distribuer son app ailleurs que sur le App Store aussi ...
avatar ClementB | 
"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." Oui et non : UNIX et tous les systèmes qui en dérivent (dont Mac OS X) séparent bien le noyau de l'espace utilisateur, dans lequel les programmes ne peuvent accéder aux ressources matérielles que via un jeu restreint de fonctions dites appels systèmes. En gros, le sandboxing fait un peu la même chose, mais à un étage supérieur du mille-feuilles...
avatar PiRMeZuR | 
J'espère que ce ne sera pas aussi contraignant que sur Windows. Au moment du passage à Vista, le système a commencé à interdire tout plein d'endroits où enregistrer ou charger des fichiers. J'ai du pondre en urgence plein de mises à jour pour changer les répertoires utilisés car les apps plantaient... Enfin, là on ne prend pas le bon chemin...
avatar Mark Twang | 
@yoa : 'L'informatique se dirige vers un système aseptisé où l'utilisateur n'est plus qu'un consommateur cloisonné dans l'écosystème de l'éditeur.' C'est ce que j'attends du Mac. Je bidouille sous Windows et Linux, et quand je plante le système je réinstalle tout. Mais sur mon Mac je veux être tranquille.
avatar amnesic | 
Il y a un très bon billet sur le sujet ici : http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html
avatar Mister_sam32 | 
Très très bonne article ! Bien détaillé ! Nickel !
avatar Geoffrey198 | 
Excellent article! Peut être que quelques développeurs expérimentés pourront apporter des réponses aux questions que je me posais à la lecture ce petit pavé... Le sandboxing engendrera-t-il une réelle perte de "flexibilité" à long terme ? Ou est-ce que les développeurs auront juste à acquérir de nouveaux réflexes lors du développement d'applications MacOS ? Quid de la portabilité des application écrites dans un langage multi-plateformes ? Faudra-t-il revoir son code en profondeur pour avoir une application qui tourne sous Mac OS ?
avatar dtb06 | 
Comme le dit ClementB, le système Unix est déjà assez sécurisé. Si on ne permet pas à une application de tourner directement avec les API du système, c'est qu'on reconnaît implicitement que ces API sont susceptibles d'être buggées avec des failles qui ne sont pas comblées assez vite. Ca induit principalement des limitations importantes au niveau des applications proposées, dans l'article il est cité le protocole FTP qui est quand même quelque chose de courant ! Qu'on améliore la sécurité de l'OS, c'est bien, mais il me semble que par exemple tous les systèmes récents ont mis en place la sécurisation et l'attribution aléatoire de zones mémoires. Qu'on limite les applications à des "portes" aussi restreintes avec le système me semble abusif. Il faut aussi arrêter de comparer un OS d'ordinateur avec un OS de téléphone. Le but d'un ordinateur, et c'est pour ça que les gens l'achètent, c'est de pouvoir faire des choses très différentes comme éditer de la musique, compresser des vidéos, faire des entrées/sorties sur les ports USB ou autres ! C'est une philosophie différente d'un disque dur multimédia ou d'un téléphone ! Je pense qu'Apple se trompe en "bridant" les macs, car si mon ordinateur est limité à un navigateur spécifique, ne peut pas faire de FTP ou autres, alors moi je n'en ai plus l'utilité ! En plus c'est souffler le froid et le chaud, car d'un côté ils ont ouvert et permis d'installer Windows sur un Mac et de l'autre ils restreignent ce qui peut s'installer sur OSX. Je ne veux personnellement pas qu'OSX devienne un OS "light" qui permette juste d'installer 2 ou 3 applications agrées et bénies par Apple. Au fait, je n'ai pas d'ipad, et je suis resté en Snow Leopard... Quand je vois les "hacks" qu'il faut faire pour éviter les options de Lion imposées par Apple comme la reprise automatique, l'affichage des dossiers système ou la partition de restauration (et le fait qu'on ne puisse pas désactiver l'autosave, ça me fait peur...
avatar mikael34 | 
Donc au final les dossiers "téléchargements" n'existera plus ? On aura un dossier pour les téléchargements de Safari, un autre pour firefox, un autre pour Chrome etc... Le dossier Documents va disparaitre aussi j'imagine ? Ca va être simple au quotidien... J'ouvre mon éditeur html, je travaille sur mon projet, je le subversionne, il faut aller chercher manuellement le dossier dans la sandbox de l'editeur html (en imaginant qu'il puisse écrire dedans pour les bases subversions ? ). Ensuite j'envoie mes fichiers en ftp, rebelote... Le gros problème du sandboxing c'est bien le partage d'informations entre les applications... On voit ce qui se passe sur ios, c'est un immense bordel, mais mon mac je m'en sers 10h par jour pour bosser, si tout est comme ça, ce sera un enfer.
avatar Orus | 
Oui excellent article qui ne donne qu'une seule envie : passer sous Windows, Linux ou autres. "la tombée en désuétude du Finder" voilà une affirmation bien tranchée et fausse. C'est sur le Finder ça peut paraitre compliqué à la ménagère ou au débile qui ne sait se servir que de son iPhone. Alors plutôt que de leur expliquer, Apple se met à leur niveau. Pathétique. Alors si le Macintosh ça devient des iTruc et des iBidules, alors adieu Apple.
avatar curly bear | 
Merci pour ce résumé. Mais quid de l'accès à internet et à l'exécution de java ou Javascript dans ces pages ? Aussi, est-ce qu'on pourra toujours proposer l'ouverture de fichiers récents dans le sens où la première fois on passe bien par une fenêtre 'ouvrir' mais pas ensuite ?
avatar BeePotato | 
@ Mikael34 : « accès en lecture / écriture aux fichiers que l'utilisateur a explicitement sélectionnés avec le dialogue Ouvrir ou Enregistrer » L’éditeur HTML aura tout à fait le droit d’enregistrer des fichiers où tu le voudras. Le client FTP aura tout à fait le droit d’aller les y chercher. Simplement, ils n’auront plus le droit d’aller enregistrer ou lire n’importe quel fichier sans que tu le leur aies spécifiquement demandé. En théorie, ça ne devrait donc pas gêner ces usages ni le partage d’informations entre les applications de cette façon (via des fichiers créés dans une appli et ouverts dans une autre).
avatar macdr | 
Par pitié, ne prenez pas au sérieux Bertrand Serlet quand il parle du cerveau humain... Rien de comparable avec un ordinateur, des programmes et des jeux d'instructions.
avatar r e m y | 
L'obligation du sandboxing pour les applications distribuées via le Mac appStore à partir de Mars 2012, doit-il être compris comme "en mars prochain, seuls les Macs tournant sous Lion pourront utiliser les applications de l'appStore" ?
avatar BeePotato | 
@ dtb06 : « Comme le dit ClementB, le système Unix est déjà assez sécurisé. Si on ne permet pas à une application de tourner directement avec les API du système, c'est qu'on reconnaît implicitement que ces API sont susceptibles d'être buggées avec des failles qui ne sont pas comblées assez vite. » Non. Ça n’a rien à voir avec les bugs, mais avec les droits d’accès que donnent ces API. Les sécurités dans Unix (et d’autres systèmes) sont fondées sur la logique qu’une application d’un utilisateur n’a pas à avoir un accès implicite à tous les niveaux de la machine et de l’OS. Le sandboxing présenté ici repose sur une logique similaire : la réalisation qu’il n’y a aucune raison pour que chaque application lancée par un utilisateur ait implicitement le droit d’aller lire et modifier l’ensemble des données de l’utilisateur. Dans le cadre d’un OS pour ordinateur personnel, c’est en fait un aspect bien plus important que le premier, ce qui compte le plus pour l’utilisateur étant la protection de ses données. Il semble donc logique de tenter de mettre en œuvre ce genre d’approche limitant les droits implicites des applications. Logique, mais pourtant j’ai moi aussi du mal à imaginer que ça remportera un grand succès. Je ne sais pas trop bien pourquoi, puisque ce sera finalement invisible de l’utilisateur pour la plupart des applications, et les autres seront toujours disponibles via d’autres canaux de distribution que le Mac App Store. Probablement une réaction irrationnelle, donc. J’imagine qu’on verra à l’usage.
avatar lukasmars | 
La sécurité a bon dos décidément... Comme si OS X n’était pas déjà trop fermé, Apple va trop loin .

Pages

CONNEXION UTILISATEUR