Fermer le menu   
header

OS X Mountain Lion : les développeurs, Gatekeeper et le sandboxing

par Anthony Nelzin le 21 février 2012 à 18:15

À partir du 1er mars, toutes les applications distribuées dans le Mac App Store devront utiliser le système de sandboxing d'OS X. La transition n'est pas simple : ce système permet certes d'augmenter la sécurité de l'utilisateur, mais n'est d'une part pas infaillible et d'autre part pas toujours aussi complet que les développeurs le voudraient. Pire : à deux semaines de l'échéance, Apple a présenté dans OS X Mountain Lion une alternative potentielle au sandboxing. Qu'en est-il vraiment ?

Sécurité

Sandboxing : jouer dans un bac à sable
Le sandboxing est une pratique héritée d'iOS : une application placée dans le "bac à sable" doit demander la permission au système d'utiliser un jeu réduit de fonctions et d'accéder à un ensemble réduit de fichiers. Apple détermine l'étendue du bac à sable en restreignant le nombre de permissions et en contrôlant le fonctionnement du système par un jeu de signatures. Le tout est censé répondre à un double argument, sécuritaire et pratique (pour aborder plus en détail le sandboxing : lire : OS X Lion : comprendre le casse-tête du sandboxing).

Ce système restrictif pose néanmoins de nombreux problèmes aux développeurs, notamment à ceux d'utilitaires ou d'applications complexes, exclus de facto du Mac App Store. Beaucoup s'en sont émus, et certains ont rempli des rapports de bogues pour obtenir l'attention d'Apple — à l'écoute, la firme de Cupertino leur a répondu. OS X 10.7.3 contient ainsi de nouvelles permissions et des permissions mises à jour :

  • interaction avec les appareils FireWire (sauf accès direct aux appareils audio / vidéo comme les caméras DV) ;
  • interaction avec les appareils Bluetooth ;
  • interaction avec les appareils série ;
  • accès aux appareils HID (joysticks, etc.) via la permission d'interaction avec les appareils USB ;
  • possibilité de graver des disques optiques ;
  • accès plus permissif au Carnet d'adresses ;
  • modification de la luminosité du système ;
  • exécution de commandes depuis /bin, /sbin, /usr/bin et /usr/sbin ;
  • création et connexion libres de sockets du domaine UNIX ;
  • transmission de signaux aux processus enfants.

Certaines de ces nouvelles règles lèvent les doutes sur des applications : la gestion du FireWire et du Bluetooth, par exemple, ne limite plus certains utilitaires. Reste que la liste est encore et toujours trop limitée, et certains développeurs n'ont d'autre choix que de quitter le Mac App Store. Atlassian a ainsi annoncé que SourceTree, son client Git, Mercurial et Subversion, ne serait désormais plus disponible que sur son site web. Manton Reece a aussi des doutes concernant le maintien de son application Clipstart dans le Mac App Store, comme Pieter Omvlee, le développeur de Fontcase.

Sandboxing

De manière générale, le bac à sable est conçu avec l'idée que le système est une machinerie de moins en moins visible et de plus en plus transparente, un ensemble de services assemblé comme un moteur pour de multiples applications spécialisées, et non une immense plateforme généraliste. Il est donc très adapté aux applications d'édition de documents, qui sont par essence confinées dans un « espace » réduit — mais des applications comme SourceTree, Transmit qui ont besoin d'un accès permanent au système de fichiers, ou des surcouches système comme TextExpander s'accommodent très mal au sandboxing.

[MàJ] Quelques heures après la parution de notre article, Apple a annoncé qu'elle repoussait la date limite d'adoption du sandboxing du 1er mars au 1er juin 2012 (lire : Apple repousse la date limite pour l'adoption du sandboxing).

Gatekeeper : jouer librement dans un parc fermé
L'obligation pour les applications du Mac App Store, canal privilégié de distribution, d'utiliser le sandboxing est conçue par Apple comme un moyen de renforcer la sécurité de l'utilisateur. Le Gatekeeper d'OS X Mountain Lion va encore plus loin : il impose certains éléments de la sécurisation du Mac App Store à l'ensemble des applications distribuées par d'autres moyens (lire : Gatekeeper : le garde-chiourme de Mountain Lion & Gatekeeper : des satisfecit teintés de prudence ).

Apple se pose en autorité de certification et va fournir un système de signatures numériques à l'ensemble des développeurs OS X, comme c'est déjà le cas pour ceux qui distribuent leurs applications via le Mac App Store. Cette signature identifiera l'application et son développeur : si une application récupérée depuis Internet se révèle malintentionnée, Apple peut la désactiver, la signaler comme malveillante à son installation, voire étendre la protection à l'ensemble des applications du développeur concerné.

Par défaut, seules les applications signées, qu'elles proviennent du Mac App Store ou d'autres sources, pourront s'exécuter sur OS X Mountain Lion. Les utilisateurs avancés auront le choix de restreindre un poste aux seules applications de la boutique d'Apple, ou au contraire d'ignorer cette couche supplémentaire de sécurité. Ce système, qui avait notamment été suggéré par Wil Shipley, permet d'obtenir un bon niveau de protection tout en gardant une grande flexibilité : il ne fait que mettre en lumière les limites du sandboxing.

Les déboires récents de l'équipe de validation d'Apple montrent que les App Store ne sont pas infaillibles, et peuvent laisser passer des applications qui ne font aucun mal… sauf peut-être à votre porte-monnaie (lire : App Store : Apple fait la chasse aux imitations). Aucun système de sécurité ne pourra s'interposer face à ces véritables arnaques qui fonctionnent grâce à l'inattention et l'inexpérience de la majorité des utilisateurs.

Le sandboxing lui-même n'est pas infaillible : à partir de quelques permissions anodines et au travers d'une potentielle faille, une application malintentionnée peut causer le chaos dans votre système… avec la bénédiction de celui-ci ! Pourquoi s'encombrer de ce système donc, s'il est si incomplet et si Gatekeeper est si sûr et flexible ? Tout simplement parce que le système des signatures n'est pas non plus à l'abri de potentiels problèmes (lire : OS X Lion et le problème des certificats TLS/SSL).

Gatekeeper

C'est bel et bien la combinaison du sandboxing et de la signature numérique qui permet d'améliorer globalement la sécurité, au prix de quelques ajustements pour les développeurs. C'est ainsi que fonctionnent les applications du Mac App Store — mais même dans OS X 10.8 Mountain Lion, les applications obtenues hors du Mac App Store pourront se passer du sandboxing et potentiellement causer des dommages avant la révocation de leur signature. Ainsi Craig Hockenberry explique maintenir désormais deux versions de XScope : une sandboxée et signée, distribuée dans le Mac App Store, et une sans bac à sable, distribuée sur son site web. On le comprend bien dans son cas — et c'est un développeur connu et reconnu — mais on peut voir les éventuels problèmes que cela pourrait poser dans la situation d'un développeur moins bien intentionné.

La solution est peut-être l'approche proposée par Daniel Jaikut, le développeur de MarsEdit : obliger tous les développeurs, qu'ils distribuent leurs applications dans le Mac App Store ou d'ailleurs, à utiliser le sandboxing et la signature numérique. Cela représenterait certes une plus grande charge de travail au moment de l'adaptation, mais Apple a toujours privilégié la sécurité et le plaisir de l'utilisateur au confort du développeur. Cette décision forcerait les développeurs à adopter les deux mécanismes, et participerait à maintenir la relative sécurité d'OS X. Elle requiert néanmoins qu'Apple soit plus à l'écoute, et réagisse plus rapidement pour inclure les permissions nécessaires à l'exécution des applications les plus complexes (quitte à permettre à celles-ci de franchir le bac à sable contre une surveillance renforcée).

On atteint là la limite de ces mécanismes : la volonté d'Apple de les promouvoir, et sa capacité à le faire. Cette approche mixte qui se dessine dans OS X Mountain Lion et qui pourrait devenir obligatoire dans ses successeurs ne fait que renforcer la frustration causée par le manque chronique de communication à moyen et long terme par Apple, qui ne permet pas à ses partenaires de valider certains choix financièrement lourds. Un véritable défi, mais qui pourrait être une des plus belles réussites de la firme de Cupertino dans le domaine, si elle parvenait à le relever.

Catégorie : 

Commentaire(s)

avatar Armas 21/02/2012 - 18:28

Je privilégierais toujours les applications qui ne seront pas tirées de l'app store. Le sandboxing est une régression technologique trop contraignante par rapport à ce qu'elle apporte. Elle ne sera utile que pour les néophytes qui ne connaissant pas encore bien l'environnement mac mais risque de devenir un vrai boulet à trainer pour les utilisateurs avancés qui utilisent des logiciels un soupçon plus évolués.

Je me demande comment peuvent fonctionner des logiciels comme little snitch dans de telles conditions.

avatar Francis Kuntz 21/02/2012 - 18:39

J'allais justement dire le contraire. Je privilégies les applications du Mac App Store et en particulier avec l'application du sandboxing qui fera le ménage dans les applications codées avec les pieds.

avatar Jimmy_ 21/02/2012 - 18:43

Apple a réussi à faire pire que Palladimum.

Mais bon restreindre les libertés au nom de la sécurité c'est dans l'air du temps.

Prochaine étape, envoyer son empreinte génétique à Apple pour être certains que c'est le bon utilisateur.

avatar lmouillart 21/02/2012 - 18:49

@Francis Kuntz le passe au sandboxing ne s'effectue pas en un claquement de doigts, typiqmement Redhat met ce type de solutions en oeuvre depuis 2004. Il y a effectivement beaucoup de code à modifier et de règles d'accès à définir.
Ce que je ne comprends pas c'est pourquoi ils ne se sont visiblement pas basé sur les architectures FLASK qu'on peu trouver dans TrustedBSD et notamment la partie SEBSD.

Ensuite il faudrait que les applications standards : safari/apercu/itunes/apache/le moteur de composition ... soient sandboxés, car ce sont celles qui sont les susceptible d'être attaquée.

Sinon le sandboxing est une bonne chose pour l'amélioration de la sécurité des outils informatiques.

avatar Armas 21/02/2012 - 18:59

Une application codée avec les pieds en dehors de l'appstore le restera dans l'appstore.

Le fait est que la majorité des applications présentées sur cette plateforme viennent de développeurs qui ont fait leurs premiers pas sur iphone. Ce sont des devs qui en général ne maîtrisent pas complètement l'environnement mac, voir ne maîtrisent pas l'informatique. Ils proposent pour la très grande majorité des applications basées sur l'utilisation de trois ou quatre scripts systèmes emballés dans un joli packaging mais il faudra se faire une raison. Les développeurs des meilleurs logiciels de l'environnement mac proposent également voir uniquement leurs produits en dehors de l'appstore.

avatar SolMJ 21/02/2012 - 19:05

[quote]Ensuite il faudrait que les applications standards : safari/apercu/itunes/apache/le moteur de composition ... soient sandboxés, car ce sont celles qui sont les susceptible d'être attaquée.[/quote]

Tu es sûr d'avoir bien compris le principe du sandboxing ?

Le sandboxing ne protège pas les applications des "attaques". Elle protège le système des applications (qui sont "sandboxées").

avatar Psylo 21/02/2012 - 19:07

[i]Le sandboxing est une pratique héritée d'iOS[/i] mais qui existe depuis belle lurette, comme par exemple les chroot jail sous FreeBSD.
Macgénération, la Pravda, en pire.

avatar Artanis 21/02/2012 - 19:08

@ Armas:
le bac à sable est très utile d'un point de vue sécurité. C'est juste trop limité pour certains programmes. Pas grave, ça n'empêche pas de l'utiliser la plupart du temps, et de passer outre pour le reste.

avatar Artanis 21/02/2012 - 19:12

@ lmouillart:
J'avoue que je n'ai pas suivi ça de très près, mais il me semble que Safari progresse, de ce côté-là. Les infrastructures sont un peu longues à se mettre en place, mais ça va dans le bon sens.

avatar Artanis 21/02/2012 - 19:14

@ Psylo:
Remplace mentalement "pratique" par "implémentation", peut-être?

avatar Anthony Nelzin 21/02/2012 - 19:19

@Psylo : parce que FreeBSD est produit par Apple, de laquelle on parle dans cet article ?
@lmouillart : Safari, Mail et Aperçu sont sandboxés.

avatar joneskind 21/02/2012 - 19:39

@Psylo

C'est quoi ton problème ? En quoi le fait de dire "j'ai hérité du gout de la musique de mon père" sous-entend "mon père a inventé la musique" ?

J'commence vraiment à en avoir marre de tous ces rageux complètement abrutis.

avatar lmouillart 21/02/2012 - 19:51

@SolMJ
"Le sandboxing ne protège pas les applications des "attaques". Elle protège le système des applications (qui sont "sandboxées")."
C'est exactement le cas : l'idée est qu'un débordement de pile ou autre d’aperçu/apache/... ne puisse permettre de sortir du contexte du bac à sable pour mettre en péril l'OS.

avatar Kringe 21/02/2012 - 20:24

Bien moi je trouve qu'il y a beaucoup d'application de l'appstore qui ne sont pas sandboxées alors qu'elles devraient l'être. Il faudrait donc choisir d'imposer un sandbox au cas par cas selon moi.

avatar Philactere 21/02/2012 - 20:48

Question aux spécialistes sur un point pas clair pour moi : le sendboxing protege-t'il le système uniquement des applications volontairement malveillantes en les confinant dans un bac à sable ou également de bugs d'applications "honnêtes" qui ouvriraient des failles (cas de buffer overflow comme dit par lmouillart ?) exploitables par des applications malveillantes sendboxees ou non ?

C'est une question qui peu intéresser l'utilisateur (averti). Je pourrais m'imaginer installer des applications non sendboxées quant j'ai une entière confiance dans l'honnêteté de l'éditeur mais privilégier uniquement des applications sendboxées dans le cas de petits éditeurs moins reconnus par exemple.

Bref ce qui peu être intéressant dans le sendboxing c'est de pouvoir faire le tri entre le bon grain et l'ivraie tout en pouvant utiliser l'ivraie de manière sécurisée.

avatar lmouillart 21/02/2012 - 21:05

@philactere
Le sandboxing permet d'isoler une application/ un composant et de la faire communiquer par le biais de canaux identifier avec l'OS ou d'un système.

En gros disons que ton OS correspond au centre des nations unis, tu veux laisser des personnes (les programmes) communiquer avec les émissaires (l'OS) mais tu ne souhaite pas qu'ils se fassent trucider. Tu vas donc passer par des sas de sécurité montrer tes papiers (gatekeeper), dire ce que tu souhaite y faire (liste d'accès), et faire des choses suivant le protocole des nations unis (l'objectif de ton programme).

Ca ne t'empeche pas d'être porteur de virus biologique (ton identité reste la même).
D'être en fait mal intentionné mais de montrer patte blanche
De te faire corrompre par des organisations terroriste.

Ce bien évidemment soumis aux capacité de contrôle des services de sécurité des UN (possibilité de sortir du bac a sable)

Si tu as confiance à part égale dans tous les éditeurs les applications à sandboxé en premier sont celles qui ont beaucoup de failles de sécurités : itunes, safari, cups, appercu, flash, acrobat reader, apache.

Si tu n'as pas confiance en ton éditeurs le sandboxing est préférable dans tous les cas.

Les logiciels des gros éditeurs sont souvents très exigeants en terme de besoins d'accès à l'OS et bypassent touts ces mécanisme ou nécessitent leurs désactivation.

avatar Domsou 21/02/2012 - 21:16

@Armas :
'Les développeurs des meilleurs logiciels de l'environnement mac proposent également voir uniquement leurs produits en dehors de l'appstore.'

Lesquels ? Et pourquoi les logiciels sur le Ac App Store devraient être moins bons ?

Pixelmator ?

avatar liocec 21/02/2012 - 21:36

"obliger tous les développeurs, qu'ils distribuent leurs applications dans le Mac App Store ou d'ailleurs, à utiliser le sandboxing et la signature numérique."

C'est pas mal ça... Après on impose de valider les sources, on impose de donner sa CB, de baisser son froc...
Que c'est beau la liberté made Apple !

Heureusement il y aura la passoire Windows qui permetra de développer instablement, mais librement !

avatar lmouillart 21/02/2012 - 21:54

@liocec Windows à ce fonctionnement depuis 2004 pour les des DRM, signatures des archives et executables, et le mécanisme de sandboxing date de Windows 2000.

Ensuite Windows n'est pas une passoire, ce sont les paramétrages par défaut qui sont permissifs. Utilise un Windows sécurisé tu verra que ce n'est pas spécialement passoire.

avatar thierry37 21/02/2012 - 22:08

Y'a un truc que je ne comprends pas avec ces signatures.
Un gars fait un logiciel signé et accepté par Apple.
Ensuite il fait une mise à jour avec de mauvaises intentions cachées. Ça passe. Tout le monde met à jour et Ça fout le bordel ds leurs macs tant que la signature n'est pas révoquée ?

Y'a le temps de faire de gros dégâts. Non ?

avatar denmakesmusic 21/02/2012 - 22:10

moi je n'ai jamais eu aucun problème de sécurité sur Mac depuis 1995 en installant tout un tas de logiciels... c'est de la parano doublée d'une volonté de forcer les developpeurs à passer par l'AppStore (et donc de payer) et de les enfermer dedans.

avatar Anthony Nelzin 21/02/2012 - 22:14

@thierry37 : oui. D'où le fait que seul, ce n'est pas le système ultime. Et d'où le fait que ce n'est pas le seul système pour le Mac App Store, où il est associé au sandboxing.

avatar PierreBondurant 21/02/2012 - 22:38

@denmakesmusic :
c'est vrai mais avec l'augmentation des ventes de macs et le profil financier des acheteurs de mac, l'OS va devenir une cible de plus en plus tentante pour les voleurs d'identité, de données Perso (numéro de carte CB...)

Je trouve ça bien qu'apple montre qu'elle se soucie de ça et qu'elle implemente des solutions ambitieuses.
Même s'il risque d'y avoir une période de transition un peu bordélique pour les devs (lister toutes les fonctionnalités de leur soft et les déclarer lors de l'envoi de leur soft pour validation) et les utilisateurs (pourquoi mon soft préferé n'a plus telle ou telle fonction)
En espérant que ça finisse bien...

avatar liocec 21/02/2012 - 22:48

@lmouillart :
'Windows n'est pas une passoire, ce sont les paramétrages par défaut qui sont permissifs. Utilise un Windows sécurisé tu verra que ce n'est pas spécialement passoire.'

Tu te contredis : un windows sécurisé n'est pas une passoire, mais un windows fraîchement installé avec les paramétrages par défaut (sans parefeu ni anti-virus additionnel) est une vraie passoire.
Je peux t'affirmer qu'un simple fichier et hop on place un hook sur ta machine, on utilise ton email ou le web pour transmettre des données.
Évidement avec un bon parefeu, c'est beaucoup, beaucoup plus compliqué.
Idem, l'accès à la machine, aux registres est très aisé sous window

Par contre, d'expérience, sur le Mac c'est vachement plus difficile et pour ma part je m'y suis souvent cassé les dents sur la protection système.

avatar liocec 21/02/2012 - 22:55

[edit] suite....

D'autre part, windows tolère la mise en place des dll un peu où ça arrange le dev, et on se retrouve très rapidement avec un système instable.

Si tu veux faire un pari, je te compile un petit binaire rien que pour toi... Ça va t'occuper un moment et windows aussi....
Juste un thread, niveau critique, qui boucle sur lui même... sans écouter ton CTRL+ALT+SUPR

Après même si tout n'est pas rose sur OSX, tu comprendras qu'il n'y a rien à voir, c'est vraiment 2 systèmes très différents.

Pages

Connexion utilisateur