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

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

par Anthony Nelzin le Mardi 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.

|  |  

OS X Mountain disponible ! Mettez à jour votre mac pour 15,99€
3
2
1
Vos réactions (43 réactions)
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.
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.
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.
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.
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.
SolMJ [21/02/2012 19:05]

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.


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").
Psylo [21/02/2012 19:07]

Le sandboxing est une pratique héritée d'iOS mais qui existe depuis belle lurette, comme par exemple les chroot jail sous FreeBSD.
Macgénération, la Pravda, en pire.
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.
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.
Artanis [21/02/2012 19:14]

@ Psylo:
Remplace mentalement "pratique" par "implémentation", peut-être?
Anthony [21/02/2012 19:19] via MacG Mobile

@Psylo : parce que FreeBSD est produit par Apple, de laquelle on parle dans cet article ?
@lmouillart : Safari, Mail et Aperçu sont sandboxés.
joneskind [21/02/2012 19:39] via iGeneration pour iPad

@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.
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.
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.
philactere [21/02/2012 20:48] via MacG Mobile

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.
3
2
1



Réagir

attention Il n'est pas possible de réagir à cette dépêche. Si vous souhaitez toutefois réagir, n'hésitez pas à faire un tour dans nos forums.