System Integrity Protection et chiffrement : comment Apple a bétonné OS X El Capitan

Anthony Nelzin-Santos |

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.

Tim Cook a été cité comme un philosophe dans les sessions sur la sécurité et la vie privée. Même Steve Jobs ne personnifiait pas à ce point la politique d'Apple — sans doute parce qu'il n'en faisait pas un instrument politique.
Tim Cook a été cité comme un philosophe dans les sessions sur la sécurité et la vie privée. Même Steve Jobs ne personnifiait pas à ce point la politique d'Apple — sans doute parce qu'il n'en faisait pas un instrument politique.

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.


avatar byte_order | 

Bien sur que si : on abandonne la liberté de faire l'expérience de ses propres erreurs, de s'approprier *complètement* l'exploitation de son propre matériel, d'explorer le fonctionnement interne, de choisir de courir ou de ne pas courir un risque, de pouvoir vouloir le modifer, etc.

Bref on abandonne une partie de son libre arbitre en acceptant volontairement d'être traité comme des enfants, incultes, non matures, pas apte a savoir ce qui est bon ou pas pour eux dans l'usage d'un matériel dont on est pourtant propriétaire.

Faut-il le rappeler ?
Depuis toujours, on apprend de nos erreurs bien plus que de nos succès.

Le libre arbitre n'est pas une liberté mineure.

avatar BeePotato | 

@ byte_order : « Bien sur que si : on abandonne la liberté de faire l'expérience de ses propres erreurs, de s'approprier *complètement* l'exploitation de son propre matériel, d'explorer le fonctionnement interne, de choisir de courir ou de ne pas courir un risque, de pouvoir vouloir le modifer, etc. »

Non.
On n’abandonne nullement cette liberté. Elle est toujours présente et il a déjà été publié partout comment procéder. Il y a juste une étape supplémentaire afin d’accroître la sécurité du système.

« Bref on abandonne une partie de son libre arbitre en acceptant volontairement d'être traité comme des enfants, incultes, non matures »

Si c’est volontairement, ça ne correspond pas du tout à un abandon de libre-arbitre — au contraire, il s’agit de pouvoir exercer encore plus son libre-arbitre.
En fait, cette approche ne retire aucune liberté mais en ajoute une : la liberté de décider d’être traité, pour l’usage de son système informatique, comme un incompétent. Ce qui définit tout de même la plupart des utilisateurs. Évidemment, il faut un certain degré de sagesse pour savoir reconnaître son incompétence. :-)

avatar ppj505 | 

Pas d'affolement non plus, voir l'article de Macgé (https://www.macg.co/os-x/2015/06/comment-activer-le-trim-sur-os-x-el-capitan-89362), on peut toujours (espérons que ce sera encore le cas dans la version finale) désactiver rootless avec une ligne de commande

De version en version, l'accès au système est de plus en plus difficile d'accès, mais cela tiens au fait que le Mac s'est beaucoup démocratisé (pas au niveau du prix certes, mais au niveau de la diffusion) et qu'il tend à s'adresser de plus en plus à des utilisateurs "non avertis"

Il est vrai que l'on perd de plus en plus le coté sympa du Mac où on pouvait naviguer très facilement dans les entrailles du système et facilement comprendre l'architecture d'un logiciel, voire bidouiller un peu sana avoir de grandes connaissances informatique comme c'est mon cas.

Mais il reste encore encore quelques "self backdoors" et je fais confiance à des développeurs comme ceux d'Onyx que je salue et remercie au passage, qui sauront nous proposer des solutions simples (simple script derrière une case à cocher par exemple) pour désactiver cette protection avec bien évidemment le message habituel "attention pour utilisateurs avertis"

On continue

avatar pfx | 

Adieu Hackintosh ??

avatar darklinux | 

2048 , c 'est un peux léger , n ' importe quelle CPU moderne , même un Raspberry pi , peux géré du 4096 sans sourcillé

avatar elamapi | 

En fait, à la place d'Apple je réglerais le soucis à la base.

1- L'os en ROM (à l'encienne), au moins, personne ne risque de le modifier. Pas de droit root pour l'utilisateur, seul Apple dispose de la clef pour signer les updates.
2- Les updates de l'OS en Flash (basique système de lien pour surcharger l'existant) car on ne peut pas modifier la ROM.
3- Ne sont installables QUE les softs du store (signature Apple oblige).
4- Macbook/Pro/Imac soudé (et pas collé) avec une impossibilité totale de les ouvrir (pas de bidouille possible).
5- soft et data stockés sur le stockage interne qui ne sert qu'à ça (pas de système).
6- Bien sur aucun droit d'admin ou de quoi que ce soit qui puisse permettre de prendre la main sur le système.

La on est bien, même Kevin sera tranquille.

Pour les devs, facile!

Inscription obligatoire au club, 1000€ / an. Ce qui donne le droit d'avoir une machine preinstallé, avec les droits root. Système de soumission classique ensuite.

Avec ça Apple assure une sécurité max pour ses fidèles. A oui, bien sur, supression de tous les ports d'extention quelqu'ils soient. On reste chez Apple, donc tout passe par le cloud. On evite ainsi l'injection de virus ou autre.

C'est pas cool ca comme avenir ?

avatar BeePotato | 

@ elamapi : « En fait, à la place d'Apple je réglerais le soucis à la base. »

Comme quoi, on est bien content que tu ne sois pas à la place d’Apple. :-)

avatar SteveC72 | 

Je suis désolé mais ceux qui braille leur vie sur l'encadrement de OSX ne sont pas à la bonne enseigne .
Si on cherche un système libre de toute contrainte ou presque pour y faire un dev tout azimut , OSX,Windows et même Ubuntu et ses fork ne sont pas indiqué . Il existe des système libre de toutes contrainte .. En ce qui concerne OSX , les règles sont claires et précise . OSX ce n'est pas Arch .

avatar byte_order | 

Les règles sont claires et précises !?
Alors qu'elles changent régulièrement !?!

Pour rappel, le sandboxing et le Mac App Store n'existaient pas au début de Mac OS X, hein.
Etes-vous prêt a jurer que selon les règles actuelles jamais au grand jamais il sera rendu obligatoire de passer par le Mac App Store pour installer une application sur le Mac [i]OS X du futur, sauf à devoir payer une licence de développeur ?

avatar BeePotato | 

@ byte_order : « Les règles sont claires et précises !? Alors qu'elles changent régulièrement !?! »

Elles sont claires et précise à l’instant t.

« Etes-vous prêt a jurer que selon les règles actuelles jamais au grand jamais il sera rendu obligatoire de passer par le Mac App Store pour installer une application sur le Mac [i]OS X du futur, sauf à devoir payer une licence de développeur ? »

Évidemment que personne ne peut en jurer. Ce qui est régulièrement souligné, cependant, c’est que personne ne peut non plus jurer du contraire, alors que pas mal de commentateurs ici se le permettent pourtant.

avatar SteveC72 | 

C'est exactement ce que j'évoque
Si dans mon entreprise j'ai besoin d'une solution pérenne pour un service complexe , je ne le développerai pas sous OSX ou encore sous Windows bien que Windows est moins changeant que ce dernier mais bien sur une plateforme don je contrôle son évolution ..

Il ne faut jamais oublier que , les CLUF (Apple,Microsoft) nous indiques bien que nous "louons" en quelques sorte les services d'un système d'exploitation et il nous appartient en rien . Donc nous somme maitre en rien de ce que l'avenir réserve et ils ( proprio) peuvent bien faire ce qu'il désire avec .

Vous voulez que votre logiciel demeure cohérent dans un système tout aussi en phase avec votre logiciel et bien regardez du coté des licences GNU/GPL

avatar elamapi | 

Ba la seule différence entre Apple et moi, c'est qu'Apple utilise la méthode de la grenouille bouillie.

En gros,

1- Si je pose une grenouille dans une casserole d'eau froide et que je la met sur le gaz a feu doux, cette dernière va crever petit à petit sans même tenter de s'échapper.

2- Si je jette une grenouille dans une casserole d'eau déjà très chaude, elle va instinctivement tenter de sortir.

Moi j'ai proposé le 2, Apple le 1.

avatar achille70 | 
avatar dj.bea | 

Un rare article vraiment intéressant sur ce site.

avatar Le docteur | 

C'est à nous qu'il bétonne les pieds, surtout... Vous connaissez la suite.

Pages

CONNEXION UTILISATEUR