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 Shralldam | 

Et pour des solutions du style homebrew, qu'en adviendra-t-il ?

avatar Frodon | 

Homebrew installe les packages dans /usr/local, donc pas de soucis.

avatar TechGirl | 

@Frodon :
RVM et virtualenv font des symlinks dans /bin. Pas cool pour les développeurs, ça.

avatar oomu | 

parce que c'est des aides pour les FEIGNASSES.

ces projets cesseront de faire ça, se contenteront de leur binaire dans /usr/local/bin ou /usr/local/nom du produit/bin

et de laisser le développeur configurer SON environnement, et zut !

avatar oomu | 

ça ne les concerne pas.

/usr/local est d'ailleurs le dossier où on est censé ajouter ce qui n'est pas fourni par le système.

avatar blablablapple | 

Adieu Alpine!

avatar Le docteur | 

Je sens qu'il va falloir que je me méfie de deux trois trucs (Dragon, qui profitera sans doute de l'aubaine de nous refaire passer à la caisse, Wacom qui ne fera rien avant la version finale, etc).

avatar oomu | 

bien des matériels exotiques dont les pilotes ne sont pas maintenus vont mourir, oui.

avatar florian1003 (non vérifié) | 

Parfait, ils prennent le sujet au sérieux apparemment !

avatar tekikou | 

Ça va être un beau bordel.
Tout ça parce que Kévin tape son mot de passe administrateur sans réfléchir.

avatar oomu | 

Tout ça parce que les Etats ont décidé qu'on était tous un danger.

Et oui, Kevin tape trop son mot de passe.

Mais il n'est pas aidé Kevin. Clairement pas par les autorités de son propre pays ni par les nouveaux ultra-propriétaristes "web 2.0/cloud".

En effet, entre ceux qui ont peur de Kevin et ceux qui veulent vendre Kevin et sa vie, la naïveté de Kevin est finalement bien excusable.

avatar Djipsy5 | 

@tekikou :
Que cela soit Kevin ou toi, le problème est bien réel. Même toi tu as à maintes reprises donner ton mot de passe sans savoir avec assurance le processus qui s'en servirait et comment. Un simple message disant "XXXXX demande l'autorisation pour accéder à des fonctionnalités" est insuffisant pour connaître la vraie intention d'une App.

avatar Jeff06am | 

Dans quelques années le Mac aura besoin d'un jailbreak :)

avatar Anonyme (non vérifié) | 

C'est déjà le cas avec les hackintosh et ça marche plutot bien :)

avatar malcolmZ07 | 

Je vais attendre les retours avant d'installer cette version d'osx

avatar DarkSide | 

Après le bridage matériel, voici le bridage logiciel !!

avatar oomu | 

le sandboxing de OS X
ou les accès mandataires de Linux (selinux/app armor)

et autres techniques sont déjà des BRIDAGE de logiciel.

Fondamentalement c'est leur rôle. Mais un "os multitache protégé" est aussi un brideur de logiciel : il a droit de vie et mort sur les programmes, il restreint l'espace mémoire qu'il peut utiliser et lui interdit de manipuler celui d'un autre programme.

Ce n'est donc pas nouveau dans l'esprit. Les programmes ont toujours été de plus en plus restreint avec l'évolution des machines.

Les apps "managés" de .NET ou pseudo-compilé au sein de JAVA allaient déjà dans ce sens aussi.

A mon sens, l'évolution nouvelle est :
- la suppression d'un accès facile pour l'utilisateur aux droits administrateurs (sous Linux avec selinux, être root, c'est pas la fin du voyage)
- le tout cryptage (Snowden a été un coup de pied dans le cul à la communauté informatique. La confirmation de ce qui était avant des peurs ou des méfiances paranoïaques).

-
à mon sens, tant qu'on peut toujours ouvrir le capot et passer de l'autre coté du miroir parce qu'on est le PROPRIETAIRE de l'ordinateur, je ne suis pas choqué.
Je suis même ravi que l'industrie privée puisse être radicale à ce point. Car c'est une réaction aux volontés des Etats.

Mais gare à ce qu'elle ne se retourne pas contre les gens en retirant le contrôle.

avatar apossium | 

oui, je suis d'accord, je dirai meme enfin …

mais bon les pb ne sont pas qu'à ce niveau …

dans un monde numérique ou tout est / va être dématérialisé (cloud), il y a le pb des serveurs et du stockage externe qui eux seront encore plus attaqués …

La sécurité est un équilibre … si c'est plus compliqué d'attaquer le user (mac), on attaquera du Windows ou des serveurs etc …

Sachant que bien évidemment, quand on observe les parts de marché, les attaques concernent plus du Windows … voire maintenant/bientot les tablettes et smartphone !

Sebastien

avatar jju17 | 

Est ce que ça serait pas pour ça que istat menus bar ne fonctionne plus sur mon mac avec la màj 10.11 .? :)

avatar oomu | 

O_o

heu c'est la conséquence d'être tous assimilés comme des enfants de 7 à 77 ans corollaire de la folie politique, sécuritaire, mondiale généralisée.

Mais aussi du jmenfoutisme autour du spam, pub, spyware, ET DOWNLOAD.CNET.COM, complexité informatique, surveillance d'Etat, surveillance privée, hack, déni de service et j'en passe.

Le prix à payer est celui là : il est définitivement admis que l'utilisateur est seul face à l'énormité de ce qui vise son ordinateur et qu'il ne peut pas suivre.

L'industrie informatique s'arme en conséquence.

-
Je ne pensais pas qu'Apple s'engouffrerais aussi rapidement sur l'initiative d'imposer TLS.

Le tout TLS se répand. Google supprime HTTP sur ses propres services.

Les FAI vont ils se compromettre à devenir des Middle-in-the-man ?
Les Etats vont il renier les libertés civiles en interdisant le tout cryptage ? ou exiger secrètement et cyniquement des backdoors dans les produits les plus répandus ?

("les backdoors que pour les gentils, on sait pas faire")

avatar pim | 

Je suis pris d'un doute : LaTeX s'installe en /usr ou en /local ? Car OS X est tout de même une plateforme de composition sous LaTeX de prédilection.

avatar Kosua | 

A priori /usr/local/texlive (chez moi en tout cas).

avatar Keysertom | 

On pourra bientôt plus installer des logiciels obtenus par les voies non officielles...

avatar cedric1997 | 

C'est déjà le cas... Mais comme pour toutes les mesures de protection sur OS X, c'est désactivable.

avatar PEM8000 | 

A noter qu'il existe plusieurs exceptions aux dossiers interdits: par exemple /System n'est pas accessible mais /System/Library/User Template l'est toujours (en plus de /usr et /usr/local visibles sur la diapo)

avatar PierreBondurant | 

Ca va faire chier les devs et je suis désolé pour eux mais à terme, je pense que ca aura plus de bénéfices que de travers.
Enfin j'espère

Dans la mesure ou ca flingue pas les programmes que j'aime bien (istat et Little snitch au hasard), je supporte à fond tout ce qui peut nous protéger de l'espionnage étatique de masse qui n'a rien à voir avec la lutte contre le terrorisme comme on veut nous faire croire, mais le renforcement à grande échelle du contrôle des populations.

avatar cedric1997 | 

Tant qu'ils n'enlèvent pas la possibilité de modifier ces fichiers à partir du Finder... Sur Windows 8, y'a une tonne de dossiers système qui ne sont plus modifiable par l'utilisateur faute de permission (même si celui-ci est admin). Et se donner les permissions nécessaires est loin d'être une partie de plaisir.

avatar tekikou | 

@Djipsy5 :
Certes, sauf que quand j'ai un doute je ne rentre rien du tout. Kévin n'a pas cet instinct, Kévin c'est le gars qui, sur Windows, clique frénétiquement sur "Suivant" quand il installe un logiciel et installe ainsi 40 toolbars sur Internet Explorer. Je trouve ça vraiment désolant de devoir en arriver là, devoir tout bloquer parce que certains (la majorité, soyons honnête) ne sont pas capable de faire preuve d'un peu de jugeote avant de télécharger un fichier, d'entrer un mot de passe...

avatar phoenixback | 

Bon prétexte la sécurité alors que c'est juste pour gagner plus de fric avec son store mac... À gerber

avatar Hideyasu | 

@phoenixback :
Étant donné qu'Apple n'interdit pas les installations d'applications qui ne viennent pas du Mac Application Store tu dis n'importe quoi ....

Sinon je trouve que c'est une Bonne Nouvelle, certes il y aura un temps d'adaptation et beaucoup de travail pour les développeurs, mais au moins au sera tranquille niveau sécurité surtout quand on voit les lois qui passent en France !

avatar Hideyasu | 

@Hideyasu :
Mac App Store*

avatar melaure | 

Pour combien de temps encore ?

avatar Hideyasu | 

@melaure :
Ça serait malgré tout un choix très étonnant je doute que ça arrive un jours, mais Apple nous a souvent surpris c'est vrai.

En attendant c'est pas le cas donc dire que c'est à gerber ...

avatar broc_058 | 

@phoenixback :
Tu te trompes. Rien n empêche d effectuer des installations adaptées. Les développeurs devront apprendre à utiliser correctement les ressources. On a tous utiliser des fonctions avec des comportements non référencés. Cela permet de s affranchir ou corriger un problème. Mais ce n est pas la meilleure solution en terme de cycle de vie du logiciel et la sécurité.
Selinux est lourd mais efficace.
Il ne faut pas oublier que l on ne doit être informaticien pour utiliser une machine.
Cela va dans l intérêt de tout le monde.
Moins de piratage, moins de d atteinte à la sécurité de vos informations

avatar byte_order | 

En matière de sécurité vs liberté, le problème se résume souvent à savoir qui contrôle celui qui contrôle la politique sécuritaire.

Que ce soit l'état ou l'éditeur d'un logiciel informatique, qui contrôle la façon dont ils régulent nos libertés ?
Quand la réponse est "personne" ou "en tout cas, pas moi", y'a danger.

Je vous laisse répondre vous mêmes à cette question.

PS : selinux ne serait pas tolérable dans bien des cas si son code source n'était pas libre d'accès et signé...

avatar vrts | 

oula oula…

je n'ai aucune envie que mon mac devienne un ipad verouillé de partout et qu'Apple choisisse ce que je peux faire avec. Apres le hardware, vais peut être switcher aussi le software un jour ou l'autre.

avatar oZen | 

Ça semble se désactiver a l'installation dans "utilities" aussi.

avatar huexley | 

Hmm ca pue les longues procédures de tests dans mon parc xD

avatar Rayban | 

Non au contraire au taff ce serait super bien, cela empêcherai certains collègues d'installer des vpn, portail Tor et oignons pour s'amuser (draguer, tromper son conjoint, pirater) toute la journée au lieu de bosser ...

avatar TechGirl | 

Ah, je n'avais pas compris. Ces dossiers systèmes sont restreints que pour les app du Mac App Store ou pour le user root ?

avatar TechGirl | 

@TechGirl :
Dites, les théoristes, y en a un qui arrive à répondre à ma question ? :-)

avatar BeePotato | 

@ TechGirl : « Dites, les théoristes, y en a un qui arrive à répondre à ma question ? :-) »

Ben pour y répondre, ce n’est pas trop difficile, il suffit de lire l’article : « 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. » :-)

L’accès est bien bloqué même pour l’utilisateur root, d’où le surnom initial de « rootless » pour ce système de protection.

avatar TechGirl | 

@BeePotato :
Ok, merci. Donc un bon nombre d'outils de dev ne vont plus fonctionner s'ils ne sont pas updaté. Ça sent le passage sur Linux.

avatar BeePotato | 

@ TechGirl : « Donc un bon nombre d'outils de dev ne vont plus fonctionner s'ils ne sont pas updaté. »

Ben non, même pas. Il y a vraiment très peu de logiciels qui ont une quelconque nécessité de modifier ces fichiers. J’avoue que je ne vois pas quels outils de développement en particulier auraient des choses à y faire.
De plus, cette protection reste désactivable facilement si on préfère revenir au mode de fonctionnemenet traditionnel.
Du coup, passer sur Linux juste pour ça, ce serait montrer qu’on n’avait jusque là pas vraiment de bonne raison d’être sur Mac plutôt que sur un autre OS (et dans ce cas, en effet, autant passer à Linux ou un BSD tout en se demandant pourquoi on ne l’a pas fait plus tôt).

avatar BeePotato | 

Quand on voit, en réaction à l’article sur la perte d’interface graphique pour demander la réparation des autorisations, le nombre de commentaires de gens expliquant qu’ils doivent faire ça régulièrement, on comprend mieux la motivation d’Apple à bloquer les modifications dans ces dossiers.
En effet, si les autorisations d’accès à tous ces fichiers doivent être « réparées », ce n’est pas par accident ou comportement mystérieux du système, mais bien parce que des processus vont les modifier — généralement des logiciels d’installation ayant obtenu les droits root après avoir demandé à l’utilisateur son mot de passe et qui vont ensuite faire n’importe quoi là où ils n’ont normalement rien à modifier.
Du coup, cette nouvelle limitation d’accès n’est pas juste pour protéger l’utilisateur de lui-même, mais aussi pour le protéger de certains développeurs jemenfoutistes qui demandent des droits élevés à tort et à travers et font n’importe quoi avec, même si leurs applications ne sont pas à proprement parler des malwares.

avatar achille70 | 

Si je comprends bien la démarche, n'étant pas éclairé en terme technique, celui qui possède des applications (non achetées sur l'Apple Store) dans son ordinateur, et qui ne sont pas mises à jour avec le nouveau système de sécurité du nouveau OS ne fonctionneront plus???
Si tel est le cas, certains utilisateurs d'applications qui ne seront peut être pas mises à jour seront floués par des mesures de sécurités qui en interdisent l'usage.
Il est envisageable d'ailleurs que certains sociétés qui développent des applications demandent un nouveau passage à la caisse pour bénéficier de mises à jour.
En somme, ce que je retiens de "la sécurité d'Apple" c'est qu'elle enferme encore plus l'utilisateur dans son écosystème.
Je n'entends rien en sécurité, cependant, je sais que les hackeurs jouent au jeu du chat et de la souris en cherchant des failles, ils parviennent toujours à trouver des solutions.
La question que je me pose et que j'adresse aux personnes éclairées est la suivante; doit on envisager qu'à l'avenir, nous devions utiliser nos applications de travail en streaming sur les serveurs d'Apple pour être bien sûr d'éviter toute attaque.
L'avenir me fait peur, j'ai l'impression que la "sécurité" s’effectuera au détriment de nos libertés!

avatar BeePotato | 

@ achille70 : « celui qui possède des applications (non achetées sur l'Apple Store) dans son ordinateur, et qui ne sont pas mises à jour avec le nouveau système de sécurité du nouveau OS ne fonctionneront plus??? »

Non, ce n’est pas ça. Il y a très peu de logiciels dont le fonctionnement requiert d’aller toucher aux fichiers concernés par cette nouvelle mesure.

En fait, du point de vue d’un utilisateur de Mac « normal », il n’y en a aucun. Les applications ne seront pas affectées (ce qui n’empêche pas d’éventuels problèmes liés à d’autres changements dans le système, comme à chaque mise à jour de ce type).
À côte de ça, il peut y avoir quelques logiciels pour UNIX qui seraient concernés par un tel accès, mais même ça c’est plutôt rare.
Et puis il y a l’utilisateur souhaitant modifier sciemment des choses dans son système, que ce soit à la main ou via quelques utilitaires dédiés à cette tâche. Dans le premier cas, l’utilisateur est censé être assez compétent pour savoir ce qu’il fait quand il désactive cette protection, et il n’y a donc aucun problème. Dans le second cas, on espère que l’utilisateur sera suffisamment informé pour comprendre les possibles conséquences de cette désactivation.

Bref, pour l’instant, aucune inquiétude à avoir.

« En somme, ce que je retiens de "la sécurité d'Apple" c'est qu'elle enferme encore plus l'utilisateur dans son écosystème. »

Tu as été assez sage pour reconnaître en début de commentaire que tu n’étais « pas éclairé » sur ce sujet — il est dommage d’abandonner cette sagesse en formulant cette conclusion erronée. :-)
Non, ça n’enferme aucunement l’utilisateur dans un quelconque écosystème.

« doit on envisager qu'à l'avenir, nous devions utiliser nos applications de travail en streaming sur les serveurs d'Apple pour être bien sûr d'éviter toute attaque. »

Pas à court terme, en tout cas. Pour l’instant, Apple ne semble pas du tout se diriger dans une telle direction.

avatar achille70 | 

Merci de cette réponse rassurante et accessible :). Comme indiqué, je ne possède que des connaissances sommaires, souvent puisées çà et là sur internet. Le fait que j'ai exprimé cette inquiétude de l'enfermement de l'utilisateur dans l’écosystème d'Apple, ne représentait que la conséquence par rapport à mes a priori, le but étant d'obtenir, une réponse qui pouvait m'assurer que j'étais dans la faux.
J'ai lu pas mal d'articles concernant le piratage informatique, on parle souvent de la NSA, pourtant, les réseaux Mafieux ne sont pas moins dangereux, souvent installés dans des pays qui les protègent. J'ai lu quelques articles à ce sujet qui font froid dans le dos.
La sécurité est indispensable pour protéger les utilisateurs d'internet, ceci dit, j'imagine que dans quelques années, il sera nécessaire de penser différemment la protection individuelle - Les enfants et les adolescent sont aussi les cibles malléables de réseaux de toute sorte, sans les nommer.
La pornographie est disponible sans aucun filtre; souvent, les parents laissent trop de liberté - Je pense à l'affaire de Jean-Luc Lahaye qui s'indigne que facebook ait pu transmettre ses conversations privées à la police, sans s'indigner un seul instant que ses penchants soient de nature pénale.
La législation en matière de sécurité est tellement éparpillée, que les hackers savent comment exploiter les faille du système. Les premières victimes sont souvent les entreprises mal informées qui en font les frais... Il y a matière à réfléchir sur l’expansion du phénomène du "hack" dans les années à venir, et le moyen de le combattre sans restreindre nos liberté.

avatar byte_order | 

> j'ai l'impression que la "sécurité" s’effectuera au détriment de nos libertés!

C'est une lapalissade.

C'est aussi le sujet d'une citation célèbre de Benjamin Franklin, père fondateur des USA :

Ceux qui sont prêts à abandonner une liberté fondamentale pour obtenir temporairement un peu de sécurité, ne méritent ni la liberté ni la sécurité.

avatar BeePotato | 

@ byte_order : « C'est aussi le sujet d'une citation célèbre de Benjamin Franklin »

Certes.
Il convient cependant de rappeler que dans le cas présent (je parle de l’approche « rootless » d’El Capitan), on n’abandonne aucune liberté fondamentale (ni même aucune liberté, d’ailleurs). :-)

Pages

CONNEXION UTILISATEUR