Fermer le menu
 

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

Anthony Nelzin-... | | 17:30 |  48
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.
Catégories: 

Les derniers dossiers

Ailleurs sur le Web


48 Commentaires Signaler un abus dans les commentaires

avatar diegue 09/11/2011 - 20:48

Très sympa de vulgariser ce type d'articles : au moins je serai un peu moins idiot ! Quant à ceux qui veulent switcher sur MS, tout n'est pas rose dans les fenêtres ! Bravo

avatar Anonyme (non vérifié) 09/11/2011 - 21:18

Le sandboxing, pourquoi pas, mais est-ce qu'Apple se l'appliquera à ses propres Applis ? Parce que longtemps Microsoft a eu un avantage sur ses concurrents en réservant à ses logiciels certaines des API de Windows… Apple ne verrouille pas forcément pour verrouiller. Plus de sécurité, pourquoi pas, vu que les geeks d'aujourd'hui n'ont plus rien d'intelligent à faire que de s'amuser à exploiter les failles. Le sandboxing peut être l'un des rares apports positifs d'iOS à OS X.

avatar ce78 09/11/2011 - 21:35

Cet article, au demeurant excellent, révèle la direction plutôt inquiétante que semble prendre Apple. Le nœud gordien du rapprochement d'iOS et de Mac OS est bien là. Quoiqu'on fasse, à un certain moment, la sécurité est une affaire personnelle, que les barrières ne peuvent pas remplacer. On pourrait à la rigueur admettre qu'Apple fasse disparaître certains accès permettant par ex. la réalisation de sauvegardes, mais dans ce cas, il faut qu'Apple y substitue quelque chose d'eau moins équivalent, permettant au client de continuer à faire de sauvegardes. L'informatique est censée progresser, pas régresser, même au nom de la sécurité. Je suis inquiet.


avatar ZeLegolas 09/11/2011 - 21:39

@orus: +1000 => Je suis exactement du même avis que toi. Longue vie à Snow Leopard !!!

avatar Rigat0n 09/11/2011 - 22:10

Je vois pas le problème... Le Mac App Store est un choix du développeur, non ? Pour le moment, le MAS est facultatif, c'est idéal. Ce que je cherche sur le MAS c'est avant tout des applis simples, sécurisées et qui font un truc simple. Evidemment, si on cherche des trucs plus complexes, suffit d'aller voir ailleurs. Le jour où le MAS sera obligatoire je serai le premier à abandonner Mac OS, mais là...

avatar Anthony Nelzin-... macG 09/11/2011 - 22:12

@Madalvée : quand tu vois FCP X ou Xcode 4, je crois que la réponse est claire : Apple va se réserver des choses pour son usage perso.

avatar Steeve J. 09/11/2011 - 22:51

Si Apple ne fait rien pour la sécurité : ça gueule ! Et quand Apple fait quelque chose : sa gueule aussi et surtout avant que ça soit là !

avatar USB09 09/11/2011 - 23:29

@yoa : C'est une vrai question existentiel que vous posez. Vos enfants, ne sont pas pris en otages par les Média. Dirigeant, fascinant leur désirs ? C'est valable pour tout. De toute les façons, viendra un moment ou la machine supplantera l'homme.

avatar Komm 10/11/2011 - 00:23

orus a raison. Le fait de pouvoir interagir entre applications et d'avoir accès au système de fichier est crucial! Perso je me fous éperdument de la sécurité que procure le sandboxing, je travaille sur mon mac, je ne passe pas mon temps à glandouiller sur Facebook. Donc 'sont gentils chez Apple mais ils font un truc qui permette d'être productif sinon on va vite aller voir la fenêtre.

avatar AKZ 10/11/2011 - 00:38

C'est le première fois, depuis 20 ans que je suis sur Mac, que je n'adhère pas à l'évolution du système. Le rapprochement avec iOS, même si j'en comprends les raisons, m'apparaît ultra restrictif en limitant notre liberté. Sous prétexte de sécurité ou de performances on nous impose des sauvegardes, des redémarrages avec toutes les applications ouvertes avec nos derniers fichiers, une gestion mémoire qui décide des applications qui doivent rester ouvertes, etc. Et c'est très fastidieux d'empêcher tout celà (il faut souvent dire NON plutôt que OUI). La disparition des couleurs des interfaces (icônes) qui nous est aussi imposée dans les menus des fenêtres système et des applications "designed" by Apple, on se croierait à l'armée, ou tout doit être uniformisé ! Quelle sera la prochaine étape ? Ou est passé l'arc en ciel d'Apple des débuts ? On dirait que le système veut suivre Jobs dans sa tombe : il devient gris, triste et il nous enferme. Après 3 mois de test de Lion sur mon portable, impossible de m'habituer, je n'aime (toujours) pas ce système. Quand à l'app store, par curiosité j'ai fait l'essai de passer une application de mon ordinateur sur mon portable... Oui mais NON ! Il n'y a plus qu'une seule façon de faire, s'authentifer, télécharger et accepter une nouvelle intrusion. Apple télécommande désormais vos applications, alors quand vous changerez d'ordinateur, gare au bug d'identification ou au problème de connexion, et fini de jouer dans le bac à sable !

avatar ispeed 10/11/2011 - 03:41

Attendez avant de ronchonner à tout va. Pour le moment sa reste théorique et on verra en pratique. Je sens que mon xCode 4 va chauffer :)

avatar joneskind 10/11/2011 - 03:52

@macdr 9 Je commence aussi à en avoir assez de ces abus de langage et de pensée qui consistent à traiter l'homme comme une machine munie d'un OS. Un jour on va le prendre au mot et regarder le premier mec qui fait une connerie comme un OS buggé qu'il faut formater réinstaller...

avatar Thierry DL 10/11/2011 - 08:25

Un point de vue très pertinent sur le Sandboxing et la sécurité des apps Mac OS X écrit par Wil Shipley : http://blog.wilshipley.com/2011/11/real-security-in-mac-os-x-requires.html Brillant.

avatar McHerve 10/11/2011 - 09:42

[b]Geoffrey198[/b][quote]Le sandboxing engendrera-t-il une réelle perte de "flexibilité" à long terme ?[/quote]à long terme? non, à court terme déjà ! ex: tu n'as pas accès à un disque dur externe pour enregistrer tes fichiers (uniquement au bureau et à quelques dossiers -documents/video/music- tous situés dans ton dossier "maison"). La flexibilité? …plus beaucoup depuis un app MacAppStore :( Avis perso: sandboxing = quand apple fait de la sécurité en nous considérant comme des attardés incapables de se prendre en charge. à+

avatar Zouba 10/11/2011 - 10:48

[quote]Avis perso: sandboxing = quand apple fait de la sécurité en nous considérant comme des attardés incapables de se prendre en charge.[/quote] C'est pourtant le cas de l'immense majorité des utilisateurs dont le lectorat de MacGénération n'est absolument pas représentatif.

avatar Mabeille 10/11/2011 - 11:41

@dtb06 hé oui justement unix n'est pas un coffre fort imprenable ... hé oui justement cette technique tient compte du fait qu'Apple ne corrige pas si vite des failles... et souvent moins vite que d'autre. Sauf erreur Apple a été épinglé plusieurs fois pour son manque de réactivité. Reposé sa sécurité sur la réputation d'Unix est une gageur... qui sans doute peut satisfaire les personnes qu'un discours de commercial peut rassurer. Ceux qui cherchent un peu plus loin pour voir si le fameux discours est vrai ou pas (sans devenir paranon non plus) ne seront pas dupe longtemps. Ne pas douter du discours d'un vendeur ne fusse-t'il s'appeler à l'époque Steve Jobs c'est un peu suicidaire.

avatar dtb06 10/11/2011 - 12:03

@Mabeille : Rien n'est sécurisé à 100%... Mais comme on dit souvent, le problème est entre le clavier et le siège ! Je pense qu'il faut éduquer les utilisateurs. On n'utilise pas un ordinateur sans avoir des notions de sécurité et d'usage ! Quand je vois sur les forums des gens dont le Mac plante et qui n'ont pas de sauvegardes, quand je sais que certaines personnes n'ont pas de clé de sécurisation de réseau Wifi... Bien sûr, je suis pour la simplification des usages, mais je pense qu'il y a quelques bases à connaître. On ne sécurisera jamais un système, il y aura toujours moyen d'installer une application vérolée si l'utilisateur n'est pas méfiant. La plupart des virus, les utilisateurs ont double-cliqué dessus ! Je suis aussi pour le développement de matériel dédié, quelqu'un qui n'a pas de conaissances en informatique, qui veut juste faire du Facebook et envoyer 2 photos, et bien qu'il achète un ipad ! Quelqu'un qui veut acheter un vrai ordinateur, pour moi il doit être formé car c'est un outil compliqué. Sécuriser le système oui, le simplifier pourquoi pas, mais imposer des limitations contraignantes aux utilisateurs avancés juste car on veut continuer à vendre des ordi à des gens qui n'y conaissent rien, je suis contre. Pourquoi on ne fait pas dans ce cas 2 systèmes séparés ? Un système light verouillé aux applications "officielles" et un mode déverrouillé pour les utilisateurs avancés ? Mais si Apple veut aller dans le sens du système "light" sans possibilité d'usages avancés, je pense qu'ils font erreur.

avatar BeePotato 10/11/2011 - 15:07

@ McHerve : « ex: tu n'as pas accès à un disque dur externe pour enregistrer tes fichiers » Bien sûr que si ! L’utilisateur a accès aux fichiers et dossiers qu’il veut, où qu’ils soient. Ce sont les applications qui n’ont pas accès à ces fichiers tant que l’utilisateur ne leur a pas explicitement indiqué (via un dialogue ou un glisser-déposer) qu’elles avaient le droit d’y accéder. Le but est de limiter les accès automatiques à n’importe quel fichier — pas les accès voulus par l’utilisateur. Faut essayer de comprendre le modèle avant de le critiquer…

avatar BeePotato 10/11/2011 - 15:08

Notons à ce sujet que l’exemple du client FTP donné dans l’article est très mauvais.

avatar Mabeille 10/11/2011 - 15:13

@dtb06 chez M$ ils essayent depuis longtemps de trouver une solution pour ce qu'il y a entre le calier et l'écran mais peine perdue... et ce qu'il y a entre le clavier et l'écran chez Apple n'est guère mieux, voire pire à cause de la légende: y apas de virus sous Mac... Enfin passer a un pad n'y change rien, on vient de voir passer une faille sous iOs qui permet de contourner les protection de l'app Store... donc ta solution n'en est pas vraiment une. Cette "erreur" est faire depuis vista par microsoft et ça marche pour eux: windows 7 n'est pas un bide loin s'en faut. Il me semble que le sandboxing est une solution où les dev vont devoir se sortir les doigts et arrêter de faire du copier coller de code pour sortir un upgrade de leurs softs. Mais cette version reporte la charge sur les plus "compétents" (dev) et déleste les moins compétents (users).

avatar Mark Twang 10/11/2011 - 15:28

@Mabeille : 'Il me semble que le sandboxing est une solution où les dev vont devoir se sortir les doigts et arrêter de faire du copier coller de code pour sortir un upgrade de leurs softs. Mais cette version reporte la charge sur les plus "compétents" (dev) et déleste les moins compétents (users).' C'est ce qu'il me semble aussi.

avatar lmouillart 10/11/2011 - 16:21

Pourquoi Apple n'a elle pas utilisé SE Linux qui tourne notamment sur FreeBSD ce qui ne devrait pas poser de problème pour Darwin & MacOS X ? SE Linux est beaucoup moins intrusif dans la plupart des cas que ce que propose Apple.

avatar fantomx6 11/11/2011 - 10:58

C'est le repère des réactionnaires ici, ou quoi ??? C'est de la sécurité du système ET des données dont il s'agit. C'est justement parce que les développeurs se permettent n'importe quoi que ce genre de chose apparait et se met en place. Il suffit de regarder ce qu'il se passe au niveau des logiciels de musique. Prenez par exemple la philosophie "OLD SCHOOL" des DAW traditionnels (Logic, Cubase, Sonar, GarageBand,etc...) et voyez la gestion du workflow. Puis prenez STUDIO ONE de Presonus et son approche différente. Pour STUDIO ONE, l'instrument ou l'effet c'est "le dossier" et les paramètres sauvegardés sont "les fichiers". Pour les Morceaux, tous les éléments sont dans le "Bac" du Morceau et non dans un fatras de fichiers répartis au hasard. La notion de Navigateur de "média" prend ici tous son sens. En conclusion, il n'y a que les imbéciles qui changent pas d'avis.

avatar clem95 11/11/2011 - 14:43

le plus gros problème du casse tete du sandboxing impératif sur le MAS c'est que ca ne présage rien de bon. Perso pour moi c'est pas un casse tete puisque je n'ai pas que du apple à la maison...

avatar mimot13 11/11/2011 - 15:18

je confirme, excellent article (et donc merci à macgénération) mais inquiétant en même temps pour les utilisateurs des futures releases d'OS X. La non ouverture pou iOS ne me gêne pas, pour OS X oui et ceci pourrait justifier, à terme un (re)passage définitif à windows; système que j'utilise en parallèle de OS X de toute façon.

Pages