Cet article est un extrait (remanié) de notre livre Les nouveautés d’OS X El Capitan, disponible sur l’iBooks Store pour 5,99 €.
Plus encore qu’« une mise à jour de performances et de stabilité », selon la formule consacrée, OS X El Capitan est une mise à jour de sécurité. Il intègre un nouveau « mécanisme de défense », baptisé System Integrity Protection, qui parachève la politique sécuritaire d'Apple en assujettissant l'utilisateur root lui-même. Ce que cela signifie ? Il faut remonter quelques années en arrière pour bien le comprendre.
En 2008, d’abord, au moment de l’introduction d’un système de quarantaine dans Mac OS X Leopard. Vous avez sans doute déjà vu cette boîte de dialogue vous demandant de confirmer l’ouverture d’un fichier ou d’une application téléchargée sur le web ? C’est une manifestation du système de quarantaine, qui est censé empêcher l’ouverture automatique d’un élément que vous n’auriez pas téléchargé volontairement.
Mais ce système n’est pas suffisant : qu’un élément ait été téléchargé volontairement ne veut pas dire qu’il est fiable. L’année suivante, Mac OS X Snow Leopard a donc renforcé sa sécurité avec XProtect. L’architecture d’OS X le protège de la plupart des virus, mais ils étaient déjà passés de mode à l’époque. Depuis, la menace provient plutôt des chevaux de Troie, des applications qui cachent leur dessein malveillant sous des atours aguicheurs. Ainsi, la première infection de grande ampleur ayant touché les Mac était due à un malware déguisé en programme d’installation d’Adobe Flash.
XProtect n’est rien d’autre qu’un anti-malware intégré au système. Chaque fois qu’une nouvelle menace est repérée, la liste XProtect de tous les Mac est mise à jour. Si un utilisateur essaye d’installer une application réputée malveillante, XProtect l’en empêchera. Et s’il l’a déjà fait, XProtect désactivera l’application en question. Il reçoit encore aujourd’hui une demi-douzaine de mises à jour annuelles, preuve de l’intérêt que provoque OS X auprès des malandrins de tout poil.
En 2011, OS X Lion s’est doté d’un système de sandboxing directement hérité de celui d’iOS. Une application a normalement accès à l’intégralité des données et des ressources que l’ordinateur peut lui offrir. Cette grande liberté a permis le développement d’utilitaires système, de pilotes, et plus généralement de fonctions avancées dans les applications. Mais elle permet aussi à une application de planter l’ensemble du système et de corrompre des données en cas de gros problème.
Le sandboxing est censé prévenir ce genre d’écueil. Pour une application placée en sandbox, rien d’autre n’existe que ce que le système lui permet de voir et d’utiliser. 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, comme un enfant jouant sous l’œil attentif de ses parents.
L’année suivante, OS X Mountain Lion a renforcé le contrôle du système sur les applications avec Gatekeeper. Il impose que les applications soient « signées », c’est-à-dire qu’elles intègrent un certificat fourni par Apple. Ce certificat identifie l’application et son développeur : si une application se révèle malintentionnée, Apple peut désactiver son certificat, empêchant ainsi son utilisation sur tous les Mac sur laquelle elle est installée. Pis, cette révocation peut s’étendre à l’ensemble des applications du même développeur, bien que ce cas ne se soit jamais présenté.
Toutes les applications disponibles dans le Mac App Store doivent être signées, mais certaines applications téléchargeables sur internet ne le sont pas. Qu’à cela ne tienne : par défaut, OS X refuse d’exécuter les applications qui ne sont pas signées. Ce comportement correspond à l’option Autoriser les applications téléchargées de : Mac App Store et développeurs identifiés dans l’onglet Général de la section Sécurité et confidentialité des Préférences système. Vous pouvez désactiver Gatekeeper en sélectionnant N’importe où, mais Apple ne le recommande évidemment pas.
Les choses auraient pu s’arrêter là, mais trop d’utilisateurs cliquent sur les alertes de quarantaine sans les lire et donnent leur mot de passe à des applications à la provenance douteuse. Or « la plupart des Mac sont utilisés par une seule personne, qui possède les droits d’administration par défaut ». Que l’application se révèle malveillante, et ce sera trop tard : grâce à votre mot de passe, elle peut gagner l’accès à root et donc au contrôle de la machine.
Qui est root ? C’est l’utilisateur qui possède toutes les permissions du système. Lors de son installation, OS X prend garde à ne pas communiquer le mot de passe de root à l’utilisateur, mais le mot de passe de l’administrateur permet d’« emprunter » les droits de root, et même de changer son mot de passe. La plupart des utilisateurs de Mac utilisent un compte administrateur, compte dont le mot de passe peut donc compromettre root.
Voilà pourquoi OS X El Capitan et System Integrity Protection limitent encore un peu plus la portée des applications : même celles qui ont les droits de root n’ont plus tous les droits. Cela commence dès leur installation : les applications ne peuvent nicher de fichiers dans les dossiers /System, /bin, /usr ou /sbin. Les développeurs doivent désormais se contenter de /Library, ~/Library, /usr/local et /Applications.
Toutes les applications, y compris celles installées hors du Mac App Store qui ne sont pas soumises au sandboxing et ont accès à root, sont soumises à cette nouvelle politique. Un changement qui a une conséquence directe sur les applications modifiant le système à grands coups d’injection de code : cette pratique, déjà sévèrement restreinte ces dernières années, est désormais strictement interdite. Seuls les installeurs d’Apple et l’App Store peuvent modifier des binaires systèmes.
Les développeurs d’extensions du noyau (Kexts, « pilotes ») sont les premiers concernés par ces nouvelles restrictions. Leurs extensions doivent être signées avec un certificat spécifique, et ne peuvent plus être installées que dans /Library/Extensions. Apple a toutefois prévu que l’on puisse désactiver System Integrity Protection, ne serait-ce que pour développer des pilotes. Mais puisque root lui-même n’est pas censé y avoir accès, il faut passer par la partition de restauration (⌘R au redémarrage).
Cet article est un extrait (remanié) de notre livre Les nouveautés d’OS X El Capitan, disponible sur l’iBooks Store pour 5,99 €.
