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.
Tags
#Mac App Store #os x lion #sandboxing
avatar diegue | 
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é) | 
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 | 
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 | 
@orus: +1000 => Je suis exactement du même avis que toi. Longue vie à Snow Leopard !!!
avatar Rigat0n | 
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-Santos | 
@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. | 
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 | 
@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 | 
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 | 
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 | 
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 | 
@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 | 
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 | 
[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 | 
[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 | 
@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 | 
@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 | 
@ 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 | 
Notons à ce sujet que l’exemple du client FTP donné dans l’article est très mauvais.
avatar Mabeille | 
@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 | 
@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 | 
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 | 
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 | 
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 | 
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.
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 .

CONNEXION UTILISATEUR