OS X 10.11 - Comprendre les nouvelles règles de sécurité, Qu'est-ce qu'elles changent sur nos Hackintosh ?

[polyzargone]

Bonjour à tous.

Je vous propose ici de venir discuter des nouvelles règles en matière de sécurité introduites par OS X "El Capitan".

Le temps où OS X pouvait se vanter d'être à l'abri des virus et des malware est révolu. Sans parler des failles de sécurité propres à OS X . L'actualité récente le prouve régulièrement, et avec le succès toujours grandissants des OS d'Apple (OS X, iOS et maintenant WatchOS), les menaces sont de plus en plus présentes et il serait suicidaire de les ignorer.

Il ne s'agit pas ici de débattre sur la politique d'Apple en la matière, les news de MacBidouille ainsi que le forum "Articles & News : Vos réactions" sont là pour ça.

Non, il s'agit plutôt de discuter des implications qu'elle peut avoir sur Nos Hackintosh et sur leur fonctionnement.

Pour commencer, faisons le point :

La Developer Preview 4 et la Public Beta 2 n'autorisent plus le chargement de kexts s'ils sont installés ailleurs que dans /Library/Extensions ou /System/Library/Extensions.

Conséquence : Les kexts situés dans EFI/CLOVER/kexts/10.11 (Clover) et ceux dans Extra/Extensions (Chameleon) ne se chargeront pas. Et ce, même en utilisant les boot-flags kext-dev-mode=1 et/ou rootless=0

Pour l'instant, on ne sait pas trop si c'est dû aux bootloaders ou si c'est autre chose…

Pour rappel :

• kext-dev-mode=1 permet sous Yosemite d'autoriser le chargement des kexts non-signés par Apple ou un développeur enregistré. Sous 10.11, ce boot-flag est obsolète.

• rootless=0 est un nouveau boot-flag qui permet de désactiver l'ensemble des nouvelles mesures de protection d'OS X 10.11. Sans ce boot-flag, il est impossible de modifier le dossier System et donc de modifier, ajouter ou retirer des kexts non-signés par Apple ou un développeur enregistré. Et même dans ce dernier cas, il reste quand même des limitations à ce que peut faire un kext ou pas.

Je vous invite à lire cet article qui explique (en anglais ) assez bien le pourquoi du comment. Vous pouvez également consulter ce document (240 pages ) qui explique le fonctionnement du système de sécurité d'OS X 10.11 (source Apple).

On retiendra donc que le boot-flag rootless=0 remplace kext-dev-mode=1 et qu'il devient de facto obligatoire sur nos Hacks. Pas forcément de façon systématique mais mieux vaut l'activer en permanence si on veut pouvoir bricoler un peu les permissions et/ou reconstruire le cache (je rappelle que c'est très important sur Hackintosh ).

Maintenant, la question qui risque de se poser à terme, c'est va-t-on vers un OS X beaucoup plus vulnérable sur un Hack par rapport à un Mac du fait de la désactivation obligatoire de ces nouvelles mesures de protection ?

Si sur Yosemite, kext-dev-mode=1 ouvrait déjà un peu les vannes, sur El Capitan, c'est carrément tout le système de protection qui sera désactivé !

Voilà. Tout ceci ne sont que des interprétations basées sur ce que j'en ai vu/lu. Je vous invite bien sûr à partager vos points de vue et à me corriger si je n'ai rien compris .

[polyzargone]

Petit état des lieux en ce qui concerne les nouvelles protections d'OS X 10.11 (que l'on appellera désormais System Integrity Protection ou SIP).

Le bootflag rootless=0 permettait jusqu'à la DP4 de modifier les fichiers du dossier System et de toucher au cache système, bref, de charger les kexts non-signés indispensables à nos Hacks.

Avec la DP5 (et très certainement la PB3 lorsqu'elle sera dispo), cela ne suffit plus. Maintenant, le SIP étant activé par défaut, on ne peut plus rien toucher même si rootless=0 permet en apparence de le faire.

Deux raisons à cela :

• La réparation des permissions doit être forcée par la commande chown -Rf 0:0 car la commande chown -R 0:0 ne suffit plus et rend le(s) kext(s) "Untrusted". Et aucun kext considéré comme Untrusted ne sera chargé ni ajouté au prelinkedkernel (le cache système d'OS X) qu'il soit dans /E/L ou /S/L/E.

• Le SIP actif empêchera le chargement des kexts non-signés. Je ne sais pas trop si le simple fait de réparer correctement les permissions ou d'utiliser rootless=0 permet de contourner cela, donc dans le doute, je conseille de le désactiver aussi. À tester .

Pour cela, une nouvelle commande terminal est disponible : csrutil

[EDIT] Cette commande existe déjà dans la PB2 et probablement dans les versions DP/PB depuis les toutes premières builds.

Voici comment s'en servir :

Code

usage: csrutil <command>

Modify the System Integrity Protection configuration. All configuration changes apply to the entire machine.

Available commands:

    disable

        Disable the protection on the machine. Requires a reboot.

    enable

        Enable the protection on the machine. Requires a reboot.

    status

        Display the current configuration.

(source : InsanelyMac)

En ce qui concerne Clover et l'injection des kexts directement depuis EFI/CLOVER/kexts/10.11, les choses sont en cours et il semble qu'elles avancent bien. Par ailleurs, Pike R. Alpha semble avoir trouvé une solution (compliquée ) au problème qui devrait pouvoir être intégrée à l'ensemble des bootloaders dans un avenir très proche .

Cette solution pourrait avoir l'énorme avantage de permettre le chargement des kexts non signés tout en laissant le SIP pleinement actif et fonctionnel. Cela étant dit, c'est aussi la preuve que le SIP peut être très facilement contourné et il est fort possible qu'Apple bloque cette possibilité dans une prochaine bêta. Et d'un certain côté, ce serait même souhaitable !

Voilà, n'hésitez pas à compléter/confirmer/infirmer tout cela. J'ai sans doute oublié certaines choses et/ou mal compris d'autres .