Après le sandboxing d’OS X Lion et le Gatekeeper d’OS X Mountain Lion, voici venu le System Integrity Protection d’OS X El Capitan. Ce nouveau « mécanisme de défense » parachève les efforts d’Apple en matière de sécurisation du Mac : il assujettit l’utilisateur root lui-même.
System Integrity Protection
Le sandboxing et Gatekeeper protègent l’utilisateur d’éventuelles applications malintentionnées, mais ils ne le protègent pas de lui-même. Or comme le dit à raison Apple, « la plupart des Mac sont utilisés par une seule personne, qui possède les droits d’administration par défaut ». Un utilisateur inexpérimenté peut donner son mot de passe administrateur à un cheval de Troie qui le lui demanderait, cheval de Troie qui pourrait ensuite gagner l’accès à root et donc au contrôle de la machine.
Et cela s’est déjà produit — c’est même le seul vecteur d’infection fiable des Mac, dont la principale faiblesse est aujourd’hui l’utilisateur. Les mécanismes de protection de l’intégrité du système d’OS X El Capitan entendent régler ce problème, en restreignant au maximum la portée des applications, et donc d’une éventuelle application malveillante.
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. Ils ont tout intérêt à mettre à jour leurs applications au plus vite — OS X El Capitan fera le ménage lors de son installation, avec les conséquences que cela pourra avoir sur la stabilité des applications tierces.
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 (TRIM Enabler en est un bon exemple). Leurs extensions doivent être signées avec un certificat Developer ID for Kexts, 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 que l’on puisse 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).
L’utilitaire de configuration de la sécurité est ajouté à la partition de restauration d’OS X El Capitan. Sa configuration est stockée dans la NVRAM, ce qui signifie qu’elle s’applique à la machine entière (y compris si elle contient deux partitions avec deux systèmes séparés) et qu’elle persiste de mise à jour en mise à jour.
App Transport Security
Les développeurs vont aussi devoir faire en sorte de sécuriser toutes les connexions de leurs apps à des serveurs. Apple ne voile pas ses attaques — contre les programmes « de renseignement », contre les FAI qui injectent des données, contre les régies publicitaires qui épient l’historique de navigation. Par défaut, les applications compatibles avec OS X El Capitan (et iOS 9) ne pourront plus ouvrir de connexions HTTP non sécurisées.
Apple laisse toutefois quelques mois aux développeurs avant de leur forcer la main : « si vous avez déjà une application, vous devriez utiliser HTTPS le plus possible dès maintenant, et vous organiser pour migrer le reste de votre application le plus rapidement possible », explique-t-elle. Elle ajoute toutefois : « si vous développez une nouvelle application, vous devriez utiliser exclusivement HTTPS », ce qui ne laisse aucun doute sur ses intentions à moyen terme.
Reste que ses exigences sont très élevées : elle demande d’utiliser TLS 1.2 (la version la plus récente du protocole de sécurisation standard), interdit d’utiliser des algorithmes trop faibles (RC4 ou SHA-1) et requiert des clefs de chiffrement très longues (2048 bits pour RSA ou 256 bits pour ECC). Et comme une clef peut être compromise ou volée, Apple demande aussi d’utiliser la confidentialité persistante, qui garantit la confidentialité des données passées.
Voilà qui demande un certain investissement, ce qui explique que le chiffrement ne soit pas encore obligatoire. Mais s’ils tiennent à ce que leurs applications puissent encore communiquer avec leurs serveurs, les développeurs devront explicitement déclarer la liste des noms de domaine autorisés sans chiffrement. Le ton très ferme de la documentation sur le sujet confirme toutefois qu’il ne s’agit que d’une mesure transitoire.
Preuve, s’il en fallait encore une, qu’Apple s’inquiète particulièrement qu’un tiers puisse s’imposer entre elle et son utilisateur, elle contrôle désormais entièrement les extensions Safari. Il fallait déjà les signer, mais il faudra désormais les signer avec un Developer ID, et donc payer un compte développeur. Voilà qui signe sans doute la fin des petites extensions réalisées par des amateurs, d’autant qu’elles devront être distribuées par le biais de la galerie officielle.
