À 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 ?
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 :
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.
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).
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.
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.
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).
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.
