macOS High Sierra va bloquer par défaut les fichiers KEXT
Avec macOS High Sierra, l'utilisateur devra donner son autorisation avant qu'une extension de kernel (les "kext") conçue par un éditeur tiers puisse être chargée par le système. Plusieurs logiciels plus ou moins spécialisés et parfois assez grand public font usage de cette possibilité d'ajouter des fonctions au plus bas niveau de macOS. Il y a VMWare Fusion, Parallels Desktop, LittleSnitch, Duet Display (affichage du Mac déporté sur un iPad) ou encore Remote Buddy (pour piloter son Mac et ses applications avec toutes sortes de télécommandes, infrarouges ou non).
Felix Schwarz, l'auteur de ce dernier utilitaire, s'en inquiète. Moins pour ce nouveau tour dans la sécurité de macOS que sur la manière dont Apple l'a mis en place.
Dans une fiche technique, Apple explique que l'utilisateur verra une fenêtre d'alerte lui expliquant que le chargement d'une extension système a été bloqué mais qu'il peut néanmoins le valider. À noter que les extensions déjà présentes dans le système avant une mise à jour vers High Sierra sont acceptées d'office.
Probablement pour éviter que ces utilisateurs ne donnent un blanc-seing de façon un peu trop précipitée ou distraite, il ne suffit pas de cliquer sur un bouton pour donner le feu vert. Il faut se rendre dans le panneau "Sécurité et confidentialité" de Préférences système.
À cet endroit, un message indique qu'un logiciel système du développeur "untel" a été bloqué et un bouton d'autorisation est disponible. Ce message ainsi que ce bouton ne seront affichés que durant les 30 minutes qui suivent la tentative de lancement. Passé ce délai il disparaîtront jusqu'à ce que le logiciel installé ait à nouveau besoin de charger l'extension système. Et ainsi de suite.
Apple précise par ailleurs que les prochaines bêtas de High Sierra sauront désactiver cette protection par une ligne de commande, lorsqu'il est nécessaire de procéder à des installations en entreprise. Dans ce cas l'utilisateur n'a pas son mot à dire.
C'est tout ce cheminement et notamment la première fenêtre d'alerte passablement dissuasive pour un utilisateur lambda qui fait grimacer Felix Schwarz. L'intention est louable dit-il mais la mise en œuvre est plus discutable. Il y a un effet anxiogène avec ce premier message d'alerte qui peut servir de repoussoir sur l'utilisateur. L'éditeur peut essayer de communiquer en amont mais sans garantie que cela soit très efficace. Les utilisateurs ne sont pas toujours très attentifs aux consignes et modes d'emploi.
Au vu du nombre assez faible d'applications qui utilisent de tels fichiers d'extensions, Schwarz suggère par exemple un processus de validation des Kext par Apple (celle-ci exige déjà des développeurs de ces modules un identifiant spécifique). Pour les heureux élus il rendrait inutile ces barrières et seules les applications non validées ou porteuses de malwares devraient s'y frotter.
À voir ce que ça va impliquer pour les Hackintosh qui fonctionnent beaucoup au kext
Nul doute qu'ils profiteront de la méthode d'installation "automatique" pour les entreprises.
Ou alors, Apple va signer tous ces kext.
Mais entre nous je pencherais plutôt pour la première option xD
@ErGo_404 :
Les kext doivent déjà être signés.
exactement ma pensée à la lecture de la notification :)
@mp_
Effectivement les hackintosh sont mal barres avec a, mais sachant que les kext sont des pieces maitresses des drivers, je crains aussi pour les GPU Nividia et pas mal de "vieux" materiels (genre les instruments de mesure scientifique ou encore le secteur musical).
La proposition de Schwarz est coherente meme si elle augmente le niveau de risque car il y a eu des cas de malware sur l'App Store avec des certif detournes... Et si Apple en profites pas honteusement pour filtrer de maniere arbitraire.
Ouais, ou mon MacBook Pro late 2011 qui tourne avec Night Enabler et Continuity Activator après le changement de la carte wifi. C'est déjà assez c***** de devoir rebooter pour désactiver la SIP après chaque maj pour ensuite re-rebooter, faire les manips, re-re-rebooter, activer la SIP à nouveau et rebooter une 4e fois. Si en plus faut passer par les system prefs à chaque fois la "petite bidule rapide" devient bien longue..
Si c'est gardé en mémoire (et qu'on a pas ça a chaque lancement de l'app), c'est une bonne chose a mon avis...
Plus ça va plus il faut faire des manips pour que l'ordinateur soit utilisable. Désactivation du SIP, double authentification pour se connecter à iCloud, manips dans le Terminal pour retrouver l'option "n'importe où", et maintenant un message d'alerte pour les kext... qu'est-ce que j'ai oublié ? Le Mac était réputé pour sa légendaire simplicité, maintenant les gens n'y comprennent plus rien, on le voit bien sur les forums, ils sont désespérés et demandent de l'aide.
@sinbad21
En fait ils ferment aussi progressivement le système, à chaque nouvelle version de Mac OS c'est un peu plus de verrouillage. Jusqu'au jour où toutes les applis seront signées et qu'on ne pourra plus rien installer hors Mac AppStore. Et on se retrouvera avec un fonctionnement identique à un iPad, verrouillé et impossible à modifier (hors jailbreak). Le rêve pour Apple sans doute...
@jojo5757 :
Ben ouais, si la société dans son ensemble (capitaliste) n'était pas fondée sur le vol, peut-être y aurait il moins de... voleurs de tout genres, du voleur de films téléchargés illégalement, au pirate qui veut voler TES identifiants de carte de crédit....
@marc_os
Commentaire le plus stupide de l'année
jojo5757
C'est pas totalement vrai.
Tu peux toujours développer des applications "maison" et les installer. Apple vient d'ouvrir Homekit aux "makers" et vouloir augmenter la securite des drivers est assez legitime en soi.
SIP est aussi une tres bonne chose du moment qu'on peut le desactiver si on sait ce que l'on fait (donc que ce soit desactivable dans les options des pref de securite et en mode administrateur uniquement).
Par contre, il faut que tout cela soit fait de maniere honnete, serve reelement la securite et ne soit pas un outil monopolistique ou d'obsolescence programmee.
Et il y a des trucs qui chiffonnent au niveau de l'honnetete d'Apple et sa coherence.
Je commencerai par l'installateur de MacOS: pourquoi il n'installe pas d'office deux compte, un avec droits d'admin et l'autre en utilisateur? C'est pour tant un des fondements de la securite d'unix???
Pourquoi n'importe quel utilisateur peut valider un truc "administrateur" simplement en donnant le mot de passe. Y a rien qui ne justifie de pouvoir faire cela en dehors d'une session administrateur!
Ces deux elements sont des failles dans la protection naturelle des Unix contre les malware de type troyen.
L'autre truc qui lui est franchement malhonnete c'est l'authentification en deux facteurs qui devient un outil anti-concurrence.
J'utilise Thunderbird qui est pour moi le meilleur et le plus securise des clients mails.
Apple viens de bloquer l'acces a l'email (et calendrier) d'icloud a Thunderbird.
Il semble que la seule possibilite soit de creer des cles uniques pour chaque applications tiers (donc thunderbird). Dans le principe c'est une bonne idee, comme a on accede au service sans que le mot de passe Apple ID se balade sur le Net.
Oui, mais voila, Apple ne permet la generation de ces cles que si on active l'authentification en 2 facteurs. Ce qui n'a aucune justification technique et qui cree une faille de securite majeure: oui, l'authentification en 2 facteurs est une faille de securité!!!
Pour qui refuse de se plier a l'authentification en 2 facteurs, Apple fait donc usage d'une pratique anticoncurrentielle abusive! Aucune applications tiers, concurrentes des siennes donc, ne peut plus acceder aux services d'Apple.
Pourtant, si on peut editer son compte Apple ID ou iCloud sur le Web, il devrait etre possible de creer des cles pour les applications, cela etant independant de cette salete d'authentification en 2 facteur. :(
La Apple fait preuve de malhonnetete et d'abus de pouvoir.
@C1rc3@0rc
L'utilisateur crée n'est pas root (même administrateur soit il).
L'utilisateur qu'Apple nomme administrateur (une reprise du monde Windows) n'est que sudoers et non root. Cela fait une sacré différence.
Le seul moyen de devenir root sur Mac OS est de démarrer en single user et donc d'avoir un accès physique à la machine.
Le SIP cité plus haut en est un bon exemple. Seul root peut désactiver/activer cette fonction
Je ne parle pas de root, mais de droit d'administrateurs qui permettent d'affecter les contenu d'un autre compte, apporter des modifications profondes dans le systemes, installer des choses comme Macport (excellent au demeurant), d'installer des applications au niveau global,etc
Un trojan n'a que besoin de ce niveau pour faire un maximum de degat. Un keylogger aussil.
@ C1rc3@0rc : « Je ne parle pas de root, mais de droit d'administrateurs qui permettent d'affecter les contenu d'un autre compte, apporter des modifications profondes dans le systemes, installer des choses comme Macport (excellent au demeurant), d'installer des applications au niveau global,etc »
Oui, les droits du root, donc.
Que l'utilisateur obtient via un sudo (et seulement comme ça, il n'a pas ces droits en permanence).
@ C1rc3@0rc : « Je commencerai par l'installateur de MacOS: pourquoi il n'installe pas d'office deux compte, un avec droits d'admin et l'autre en utilisateur? »
Parce que ça ne servirait à rien d'autre qu'à emmerder l'utilisateur.
« C'est pour tant un des fondements de la securite d'unix??? »
Non.
« Pourquoi n'importe quel utilisateur peut valider un truc "administrateur" simplement en donnant le mot de passe. »
« N'importe quel » utilisateur ne peut pas faire ça : s'il n'est pas administrateur, il faudra qu'il saisisse le nom d'un administrateur et son mot de passe.
« Y a rien qui ne justifie de pouvoir faire cela en dehors d'une session administrateur! »
Si. Comme sur tous les Unix, d'ailleurs.
Pour ne pas reconnaître un « su » juste parce qu'il se présent via une interface graphique, il faut ne pas être très physionomiste. ;-)
« Ces deux elements sont des failles dans la protection naturelle des Unix contre les malware de type troyen. »
Non, puisque ces deux éléments reprennent le mode de fonctionnement classique des Unix.
@sinbad21
High sierra va devenir le Vista du Mac ???
Surtout qu'avec une ligne de commande existante, je vois pas ce qu'un script ne saurait pas faire
Encore une fausse sécurité, qui ne bloquera pas un "pro"
@dan38
Tout a fait exact!
Aller un petit exemple pour enrichir la discussion, sans reveler quoi que ce soit qui soit nouveau:
- on cree un troyen sous la forme d'une application legitime
- l'application demande le mot de passe administrateur pour s'installer, classique
- l'application installe une tache recurrente, en root, une ligne de commande qui desactive pendant un laps de temps la verification
- reste plus qu'a faire installer le kext verole pendant ce laps de temps, ça peut se faire par un systeme de mise a jour, par une autre application (troyen) ou meme en ouverture d'un site web a condition d'utiliser une faille de securite et que l'utilisateur soit un administrateur...
@C1rc3@0rc
Mais comme pour le SIP, la désactivation nécessite un redémarrage du Mac... ton troyen ne va pas être très discret à redémarrer toutes les 30 minutes! ?
Ben non, l'installateur va créer un simple daemon lancé par le processus lauchd ou cron.
Purée … mais :!
virons cocoa du mOS !! (maOS((macOS)))
et reprenons X-Window System, X11 ou tout simplement X maintenant que le «X» c'est barré du nom «Mac OS X»
J'ai comme une impression que macOS va devenir comme un vista..
..pas pu m'empêcher de penser à la pub Mac vs PC : https://www.youtube.com/watch?v=FxOIebkmrqs