Fermer le menu
 

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

Anthony Nelzin-... | | 22:00 |  65

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.

Catégories: 

Les derniers dossiers

Ailleurs sur le Web


65 Commentaires Signaler un abus dans les commentaires

avatar Shralldam 10/06/2015 - 22:06 via iGeneration pour iOS

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

avatar Frodon 10/06/2015 - 22:15 (edité)

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

avatar TechGirl 10/06/2015 - 22:55 via iGeneration pour iOS

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



avatar oomu 10/06/2015 - 23:33

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 10/06/2015 - 23:31

ç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 10/06/2015 - 22:12 via iGeneration pour iOS

Adieu Alpine!

avatar Le docteur 10/06/2015 - 22:15

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 10/06/2015 - 23:30 (edité)

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

avatar florian1003 10/06/2015 - 22:23 via iGeneration pour iOS

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

avatar tekikou 10/06/2015 - 22:27

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

avatar oomu 10/06/2015 - 23:20

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 11/06/2015 - 00:07 via iGeneration pour iOS

@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 10/06/2015 - 22:33

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

avatar Anonyme (non vérifié) 11/06/2015 - 02:02

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

avatar malcolmZ07 10/06/2015 - 22:42 via iGeneration pour iOS

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

avatar DarkSide 10/06/2015 - 22:46 via iGeneration pour iOS

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

avatar oomu 10/06/2015 - 23:16

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 11/06/2015 - 10:42

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 10/06/2015 - 23:01

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 10/06/2015 - 23:08

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 10/06/2015 - 23:16

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 10/06/2015 - 23:46

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

avatar Keysertom 10/06/2015 - 23:25 via iGeneration pour iOS

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

avatar cedric1997 11/06/2015 - 00:22 (edité)

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

avatar PEM8000 10/06/2015 - 23:51 (edité)

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)

Pages