Lion et le sandboxing
AP
Membre
Bonjour,
Je cherche à avoir un peu plus de détails sur le sandboxing et Lion. Je suis en train de me faire une petite appli de gestion de fichiers et me demandais quel est l'impact de cette nouvelle fonctionnalité.
Merci
Je cherche à avoir un peu plus de détails sur le sandboxing et Lion. Je suis en train de me faire une petite appli de gestion de fichiers et me demandais quel est l'impact de cette nouvelle fonctionnalité.
Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
On devrait toujours lire les release notes ....
- "The OS X App Sandbox"
- "Gatekeeper and Developer ID"
- "Cocoa Interprocess Communication with XPC"
- "Asynchronous Design Patterns with Blocks, GCD, and XPC"
Apple présente le mécanisme de Sandbox comme un moyen de se prémunir des virus ou d'attaques dont pourrait subir ton application. Si un Hacker trouve une faille dans ton application, en théorie, il ne pourra pas passer par ton application pour avoir accès au reste de système. En vérité ça l'embêtera sans doute un peu toute au plus. À mon avis le but est plus de faire comme sous iOS et d'obliger les applications Mac à être distribuées via le Mac App Store. Apple pouvant refuser les applications qui ne lui plairont pas tout en touchant ses 30% sur toutes les applications vendues.
Dans la pratique le mécanisme de Sandbox peut devenir un vrai casse tête. Surtout si on doit migrer une application existante pour le supporter. Sur Mac les applications sont en générale plus complexes que sur iOS. Elles interagissent plus avec le système. Les mettre dans une Sandbox peut s'avérer difficile voir totalement improductif. Le niveau de complexité étant plus grande cela peut donc obliger à revoir l'architecture complète de l'application afin d'identifier les accès dont l'application a besoin et de regrouper le code dans des Services XPC qui auront chacun des accès spécifiques. Les services XPC fonctionnant dans des process différents de celui de l'application il faudra apprendre comment communiquer avec eux. Cela peut entrainer des modifications importantes du code et induire des problèmes liés au fait que le code est éclaté sur plusieurs process. On passe d'une architecture mono-process et multi-thread à une architecture multi-process et multi-thread.
L'autre solution serait de donner tous les droits à l'application. Mais dans ce cas là si l'application est soumise sur le Mac App Store pas sure qu'Apple l'accepte.
Pour l'instant on peut encore distribuer l'application sans passer par le Mac App Store comme par exemple via un site comme MacUpdate. Mais ça ne va sans doute pas durer. La chose qu'il faut garder à l'esprit c'est qu'Apple, au fur et à mesure des nouvelles versions de l'OS, est en train de verrouiller son système. Par défaut sous Lion on peut installer les applications que l'on veut, sous Mountain Lion il faut que l'application soit signé avec un ID Developer ou qu'elle vienne du Mac App Store. Dans Mountain Lion l'utilisateur doit spécifiquement indiquer qu'il veut installer des applications autres que celles sous la supervision direct (Mac App Store) ou indirect (signé avec un ID Developer) d'Apple. Pas sure que dans la prochaine version de Mac OS X Apple nous laisse cette option. Se précipiter pour mettre son application dans le Mac App Store c'est encourager Apple à continuer à verrouiller son système.
[Maj: Ajout dans la liste des vidéos "Gatekeeper and Developer ID"]
D'un point de vue sécurité c'est pourtant une nette avancée. Ce type de mécanisme de sandboxing est simulé par les anti-virus sur les autres plateforme avec les principes d'analyse heuristique, mais cela génère trop de faux positif. Le fait de demander au développeur de déclarer ce qu'il compte faire et de se servir des actions natives de l'utilisateur pour savoir quoi autoriser permet d'intégrer un très fort niveau de sécurité logiciel sans charge supplémentaire pour l'utilisateur.
C'est réellement une bonne chose ce sandboxing, et avec des outils comme XPC et surtout NSXPCConnection on arrive à un niveau d'abstraction tel que pour nous développeur, c'est peanuts de séparer les processus exposés aux attaques du reste du logiciel.
Juste pour préciser NSXPCConnection n'existe que depuis Mountain Lion et c'est loin d'être "peanuts" quand on doit revoir l'architecture d'une application existante pour la mettre dans une sandbox. Le discours que tu as ressemble furieusement aux vidéos que j'ai pu voir sur le site d'Apple. Ces vidéos mettent aussi beaucoup en avant le Mac App Store comme platform privilégiée. Quand à l'aspect sécurité c'est discutable car sur iOS le mécanisme de Sandbox n'empêche pas les Hackers d'exploiter des failles d'applications et de Jailbraker iOS. Il y a fort à parier qu'avec l'expérience acquise sur iOS ça ne leur posera pas de pbs de passer au travers du système de Sandbox sur Mac. Le système de Sandbox alourdie le travaille de conception et de migration pour le développeur sans garantir quoique ce soit au niveau sécurité. Au final ça incitera surtout les utilisateurs à aller chercher leurs applications sur le Mac App Store. Ce qui est à mon avis le but premier d'Apple.
Sur le plan théorique le système de Sandbox devrait rendre plus sure les applications, dans la pratique Apple en a détourné l'idée à leur bénéfice afin de faire la promotion de leur Mac App Store. L'amélioration de l'"Expérience Utilisateur" n'est que de la poudre aux yeux pour les gogos.
Il faut être clair : ce n'est pas le concept de Sandbox qui me chiffonne mais plus la dépendance que l'on développe vis à vis d'Apple en l'adoptant dans le monde Mac.
Et c'est certain que le jour où je ne pourrai plus installer une application sans passer par le Mac App Store je ferai comme tablier je laisserai tomber le développement sur Mac. Un système fermé est un système qui est voué à s'éteindre. Et c'est le chemin vers lequel Apple pousse Mac OS X. Je le déplore d'autant plus car j'adore développer sous Mac, j'ai adoré GCD et je m'amuse énormément avec Objective C, repenser complétement le processus de build avec LLVM c'est un coup de génie!. Mais Apple devrait mettre plus d'énergie à améliorer sa documentation (celle sur les sur APIs de sécurité par exemple) que d'essayer de nous mettre dans une cage dorée.
Ca n'arrivera pas.
Tout simplement car il existe bon nombre de logiciels qui de toute façon ne pourront jamais être publiés sur le store. Je pense aux logiciels qui rajoutent des pilotes de périphérique, des panneaux dans les préférences systèmes, et plein d'autre choses encore.
Et je doute que chez Apple ils se soient emmerdés à mettre en place le programme "Developer ID" (qui, je le rappelle, est gratuit), qui a justement pour but de permettre la signature numérique des applications (pour gatekeeper) sans avoir l'obligation d'une publication sur le store.
Accessoirement, les certificats "Developer ID" distribués actuellement par Apple expirent en 2017...
La bac a sable n'a pas été fait pour les développeurs, mais pour protéger les utilisateurs. Donc évidemment qu'en tant que développeur tu n'en voies pas l'intérêt (parce que oui, ça complique la conception des logiciels). Sauf qu'il arrivera un jour où les utilisateurs (les clients quoi, même pour un produit gratuit les gens ont des exigences) exigerons la présence du bac à sable, pour plus de sécurité (qu'elle soit réelle ou pas).
L'intérêt du store ? Au hasard facilité la distribution des logiciels ?
Qu'est-ce qui coute moins cher ? Payer 79€ par an pour être présent sur le store, ou mettre en place/louer toute une architecture (machine, site web) et la maintenir pour distribuer soi-même ses créations, qu'elles soient gratuites ou pas ?
Par contre pour mon synthé lié à un plug-in, j'ai finalement dû me passer d'eux. A la fois, l'attrait du store m'a mis les pieds à l'étrier, et j'ai quitté Java/SynthEdit pour Core Audio/Cocoa (ce qui est bien mieux), mais au final, je me retrouve avec mon site à distribuer moi-même mes plug-ins, comme avant...
NSXPCConnection est effectivement présent que depuis Moutain Lion mais ce n'est ni plus ni mois que des objets distribués au dessus d'IPC / XPC.
Pour revenir sur ton propos "le sandbox ne change rien à la sécurité", je dois dire qu'il est juste faux.
La sécurité totale sur un système ouvert ça n'existe pas. La sécurité c'est une question de bonne pratique et de segmentation des capacités de chacun.
Voici un exemple simple montrant en quoi le sandbox et la séparations des privilèges des exécutables est un vrai gain en sécurité si appliquer consciencieusement par les développeurs.
Une application X permet d'interpréter des fichiers pour uniquement en afficher le contenu. Le parseur codé spécialement pour l'application a une faille, un buffer overflow peut être exploité avec des fichiers correctement formé.
Sans sandboxing, l'application une fois exploité va être capable de lancer un shell, se connecter à un serveur, écrire sur le disque... Bref, un simple viewer va ouvrir en grand les portes du système.
Avec sandboxing, l'application qui n'est fait que pour afficher des données n'aura pas la capacité de se connecteur au net ou d'écrire des données. La brèche sera donc contenue dans un espace plus restreint et ne présentera pas un aussi gros risque.
Maintenant si notre application à la capacité de chercher les mises à jours sur le net, pourquoi embarquer cette fonctionnalité utiliser tous les mois dans le binaire principal ? Pourquoi ne pas en faire un binaire secondaire avec des droits différents ? Celui de se connecter au net et de télécharger le package d'update dans le dossier téléchargement ? De cette manière ce binaire qui a des capacités étendu reste isolé dans son coin.
Séparation des privilèges, donc division de la surface d'attaque. C'est la règle dans tous les domaines lorsqu'on parle de sécurité.
Je suis à peu près sur que la même question posée au PC-iste aurait donné des résultats très différents.
C'est beau !!!
C'est sans doute ce qu'ils t'ont enseigné lors de ta formation pour devenir "Apple Certified Trainer"
À une autre époque je me rappel avoir suivi une formation similaire chez Microsoft et eux aussi possédaient les "bonnes pratiques". À la fin de formation j'aurai pu jurer que Billes Gates c'était Jésus (de l'informatique) !
Oui oui je sais j'ai vue les vidéos d'Apple moi aussi. Je dois reconnaitre qu'ils sont très doués en communication. Ils présentent leurs affaires de manières si convaincante... quoi que assez éloigné de la réalité.
Oui "SI" ! J'ai eu l'occasion de passer derrière des applications Mac et iOS résultat : C'est le bordel. Pas une application n'avait une architecture digne de ce nom. Je ne parle même pas des accros aux Design Pattern qui appliquaient ça plus à tord qu'à raison. Et encore heureux qu'Apple a fini par sortir ARC car au niveau gestion de la mémoire c'était le massacre ! Des développeurs consciencieuses ?!?! Je rigoles
Je suis quasiment certain que j'ai lu ça dans un manuel scolaire...
Personnellement je suis pas un expert en sécurité mais j'en connais un bon. Il m'a toujours dit que plus il y avait "de surfaces d'attaques" et plus ça facilité son travail. Il lui suffisait de s'attaquer au maillon le plus faible pour que tous l'édifice soit compromis. Et plus il y a d'éléments dans une applications, plus ça devient complexe et plus il y a d'opportunités pour lui de trouver une faille dans l'armure. Ce qui est assez injuste c'est qu'un développeur va suer sang et eau pour rendre sécuritaire son application alors qu'un Hacker n'a besoin que d'une seule erreur pour tous compromettre. La réponse d'Apple c'est de tous mettre dans une Sandbox (une boite sous leur contrôle évidemment). En gros au lieu de former les développeurs pour qu'ils apprennent à traquer des buffer overflow (et autres erreurs pouvant être utilisées par un Hacker) et à faire attention à l'architecture de leurs applications on met tous le monde dans une boite. Boite qui elle même n'est pas exempte de failles. Du coup, partant du principe qu'Apple prend en charge l'aspect sécurité, bon nombres de développeurs ne font même plus l'effort pour traquer leurs erreurs, faire attention à leur architecture et encore moins sécuriser leurs applications.
Bah sur ce coup là je ne crois pas que ce soit Apple qu'il faille blamer hein... Parce que c'est pas la faute d'Apple si maintenant dans les grandes écoles d'informatique les étudiants n'apprennent même plus ce que c'est un pointeur, vu qu'ils font tous du .NET...
Et puis tiens, j'ai envie de troller un peu, je vais donc faire une comparaison foireuse de plus avec l'automobile. En fait la sandbox, c'est comme l'ABS, ça sert à rien puisque de toute façon l'ABS ne fait que réduire le risque de mort sur les routes au lieu de le supprimer totalement... Et d'ailleurs, un bon conducteur n'a pas besoin d'ABS, tout comme un bon développeur n'a pas besoin de sandbox.
Effectivement on ne peut pas les en blâmer d'être à l'origine de cette dégradation progressive du niveau des développeurs. Par contre en mettant tout le monde dans une boite ils contribuent au processus de dégradation. Les développeurs qui veulent faire bien les choses sont de moins en moins nombreux.
Malheureusement non, Apple n'offrant pas de cours de développement ce n'est pas eux qui m'ont appris cela mais quelques autres formations que j'ai suivis telle que la CEH ( http://www.eccouncil.org/courses/certified_ethical_hacker.aspx ). ça ne vaut certainement pas ton amis mais c'est un minimum reconnu...
Bref, j'arrête là cette discussion, je ne vois pas ce qu'elle pourrait apporter de bon puisque tu refuse tout point de vue contraire au tiens...
Pour avoir été maintes fois échaudé par les beaux discours d'Apple, je suis assez d'accord avec Tof.
défaut seule les applications signées avec un Developer ID ou venant du Mac App Store pourront être installées. Après si l'utilisateur clique sur "Anywhere" il pourra encore installer des applications non certifiées. Mais comme je le disais pas sure que cette option sera encore présente dans les futures version de Mac OS X.
Dans la pratique je vois mal la plus part des utilisateurs aller d'eux mêmes changer cette option. La chose qu'ils verront c'est que l'application s'installe pas et ils iront donc sur le Mac App Store en chercher une qu'ils pourront installer.
Pour éviter de perdre des clients le développeur devra signer son application avec son Developer ID et donc s'enregistrer pour ça. C'est ce qu'ont fait la plus part des applications installées sur mon Mac en me faisant installer une version signé.
A terme la tendance va être d'obliger les développeur à signer leur application, et ça c'est une bonne chose car cela va certifier de l'identité du développeur, mais ça ne t'empêche pas d'installer une application ne venant pas du Mac AppStore.
Si une application refuse de s'installer car elle n'est pas signée par un Developer ID (et que tu n'as pas décoché l'option dans Mountain Lion), bah c'est pas plus mal car ça veut dire que tu n'es pas assurée de la provenance de l'application et que ça peut être un cheval de Troie qui se cache dans une appli ou un jeu et qui va te leurrer.
La solution, c'est de télécharger une application signée, qui va donc certifier de sa provenance (et ainsi t'assurer que ce n'est pas une version modifiée par un pirate d'une appli existante qui traà®nerait sur le net) MAIS ça ne l'oblige pas pour autant à télécharger cette application depuis le Mac App Store. Tu peux très bien aller sur des sites de téléchargement d'applis genre MacUpdate ou quoi et trouver des applications signées avec un Developer ID valide, certifiant de l'origine de l'application. (Par contre tu ne risqueras pas de te faire avoir avec une version hackée d'une application intégrant un cheval de troie, vu qu'une fois l'application modifiée la signature ne sera plus valide)
Pour info, il est possible de passer outre l'interdiction de gatekeeper sans devoir le désactiver, en cliquant sur le bundle de l'application avec le bouton droit et en cliquant sur l'entrée de menu "ouvrir".
A faire une seule fois, pour chaque application non signée.
Et alors, où est le problème, un Developer ID est gratuit...
Et franchement, la signature de code, ce n'est pas une nouveauté Apple, ça fait des années que Microsoft impose une signature numérique pour tous les pilotes de périphériques des versions 64 bits de Windows. Mais là , évidemment, le certificat est payant...
Oui, clairement, ces cons de développeurs sont même plus capable de coder directement en assembleur, alors on a du leur faire des langages évolués. Et maintenant voilà qu'ils ne veulent plus s'emmerder à gérer la mémoire...
Ca s'appelle le progrès, hein, les outils évoluent, même en informatique, les compétences aussi.
Bref, continuez à aller à la chasse au gibier avec vos lances à pointes en silex si ça vous chante. Mais la majorité préfèrera surement utiliser une arme à feu pour ça...
je suis inscrit comme développeur "gratuit" chez Apple depuis 2003! Je n'ai toujours pas compris ou je récupère cet ID!! Comme quoi nul n'est parfait et ne possède la science infuse!!
À droite https://developer.apple.com/resources/developer-id/
Je ne pense pas que Apple veuille fermer le système. Pour ça, il y a l'iPad.
Par contre, je suis plus inquiet sur leur définition de malware.
J'ai un peu peur des décisions arbitraires dans la révocation des certificats.
Je ne pense pas qu'Apple cherche à faire passer par tous les achats par le mac app store pour les 30%.
Les 30% sur les apps, ça ne représente pas grand chose pour Apple comparé aux revenus du hardware (surtout sur le Mac).
Je pense qu'ils veulent juste renforcer l'idée d'un produit simple et sécurisant. A l'opposé d'un Windows où dès qu'on installe des logiciels, on se retrouve avec des popups, une page d'accuel qui change, des 10aines d'icones dans la barre de notification, des barres d'outils de recherche dans IE, etc.
Sur Windows, il faut vraiment être un utilisateur éclairé pour garder un PC propre.
Peut-etre qu'Apple se prepare à accueillir plus d'utilisateurs sur le Mac. C'est également l'impression que donne les pubs Genius.
Ils vont peut- etre finir par sortir un iMac à un prix abordable.
Cela confirme ce que je pense depuis longtemps, un ou plusieurs Hackers agissant de manières coordonnées sont capables de rentrer n'importe ou. Pour mémoire, dans les siècles passés tout les chateaux fort on été pris. Attention, je ne dis pas qu'il faut négliger la sécurité. Je dis qu'il faut faire évoluer la sécurité pour garder de l'avance, tout en sachant que rien n'est parfait.
@Yoan Merci, je vais aller voir ça.
On mélange tout et n'importe quoi là ...
Il y a une chose importante, primordiale, que vous oubliez, la sécurité totale n'existe pas, et la sécurité du coté gentil, défensif, c'est très difficile, il faut sécuriser toutes les surfaces d'attaque possible en restant dans le cadre des lois alors que les attaquants eux, n'ont besoin que d'une seule faille et ne se préoccupent pas de la loi.
Donc oui la sécurité c'est difficile et c'est imparfait. Un attaquant ou un groupe d'attaquant sera toujours capable de passer, l'objectif d'une politique de sécurité ce n'est pas d'empêcher une attaque, si vous pensez cela, vous êtes dans le faux. Une politique de sécurité n'est là que pour ralentir les attaques et les complexifier, pour faire en sorte que les moins bon et moins motivés n'arrivent pas à leur fins et que cela laisse suffisamment de temps pour l'entreprise victime de repérer l'attaque et mettre des contre mesure.
Le cas cité par Tablier est un cas d'école, tout service est vulnérable au social engineering, surtout aujourd'hui avec les réseaux sociaux où toute votre vie est cataloguer, il suffit de bien faire son travail de documentation pour se faire passer pour la cible au près d'un service support qui ne vous connait pas.
Mais ça ne change rien au sandboxing, le principe pour Apple étant de dire, tout code exécutable doit être approuvé par un tiers de confiance. Pour les 80% d'utilisateurs non initié, le tiers de confiance sera Apple via le MAS et Apple via les Developer ID de Gatekeeper (l'idée étant de dire, si la personne prouve son identité à Apple, elle est traçable et donc part avec de bonnes intentions). Pour tout code venant d'une personne non identifié, il ne doit pas être exécuté sans l'accord de l'utilisateur qui servira ici de tiers de confiance.
Je ne vois pas comment vous pouvez dire honnêtement que c'est une mauvaise politique de sécurité...
Sandbox : au tour de MplayerX de quitter le Mac App Store
"Le développeur explique qu'il a soumis 6 versions de son logiciel à Apple, toutes refusées parce nécessitant trop de privilèges. Plutôt que de proposer un logiciel par trop tronqué (il le compare alors à Quicktime X), il a préféré renoncer au Mac App Store."
Il s'agit d'une sécurité supplémentaire.
@Tof :
En effet, le sandboxing a ses limites.