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 .

[aranaud]

Donc si je comprend bien. On devrai pourvoir mettre 0x1 à la place de 0x67 pour faire fonctionner 10.11 sur no Hackintosh ? L'utilité de BooterConfig ?

Code

<key>RtVariables</key>
<dict>
<key>BooterConfig</key>
<string>0x28</string>
<key>CsrActiveConfig</key>
<string>0x67</string>
</dict>

[polyzargone]

Donc si je comprend bien. On devrai pourvoir mettre 0x1 à la place de 0x67 pour faire fonctionner 10.11 sur no Hackintosh ? L'utilité de BooterConfig ?

En principe, tu peux même démarrer avec 0x00 à condition que tu ne rajoutes aucun kext et que tu ne reconstruises surtout pas le cache.

De cette manière, tu auras le SIP activé et le maximum de protection mais tu ne pourras plus rien faire dans le dossier System sans modifier à nouveau le CrsActiveConfig en 0x1 ou 0x3.

Mais oui, tu as raison, 0x1 suffit pour démarrer un Hackintosh sous OS X 10.11.

À mon avis 0x65 ou 0x67 ne servent absolument à rien pour le commun des mortels, autrement dit nous . À noter tout de même que certains utilitaires comme DarwinDumper par exemple ont besoin de DTrace pour créer un rapport.

Quant à BooterConfig, visiblement il ne sert à rien du tout.