10.12 Sierra Blocage du SIP ?
- Créateur du sujet RobertoP
- Date de début
M
Membre supprimé 1060554
Invité
Salut Roberto
Ta question (qui concerne «Sierra») serait peut-être mieux à sa place ici : ☞Votre avis sur macOS 10.12 Sierra☜ (mais le 2è volet de ma réponse a des implications pour «El Capitan» lui-même).
La réponse est : pareil. Ce resserrement des protocoles de sécurité a l'air bien parti pour durer. Déjà, l'OS «Yosemite 10.10» avait introduit le protocole du kext_signing au démarrage : vérification d'intégrité des extensions Apple. L'OS «El Capitan 10.11» a intégré le kext_signing comme élément d'un verrouillage plus étendu au démarrage : le SIP (System Integrity Protection), qui ajoute un verrouillage de répertoires du Système contre des modifications, une restriction de l'autorité de l'utilisateur root par rapport à ces verrouillages et d'autres limitations touchant la possibilité d'injecter du code. L'OS «Sierra 10.12» reconduit donc le SIP tel quel.
Mais la manipulation du SIP demeure la même que dans «El Capitan». Dans le «Terminal» de l'OS > seule possibilité de s'informer (= lecture) de l'état du SIP par la commande :
et exclusivité réservée au «Terminal» de la Recovery des commandes opératoires (= écriture) :
=> on peut donc pareillement désactiver le SIP depuis la Recovery de «Sierra».
L'établissement du SIP à l'installation d'un OS qui implique ce protocole («El Capitan» ou «Sierra») comporte néanmoins (me semble-t-il) une "auto-restriction". Mon MacBook Pro Late_2011 a un SSD de 1 To multi-partitionné, avec toute la gamme des OS de «Snow Léopard 10.6» à «Sierra 10.12» sur des partitions séparées (avec les Recovery collatérales à partir de «Lion 10.7»). Or, j'ai désactivé le SIP en permanence depuis mon OS «El Capitan» => à l'install de «Sierra» sur une partition dédiée supplémentaire, aucune réactivation du SIP n'a été effectuée.
Il faut comprendre que le SIP est une instruction inscrite dans la mémoire statique NVRAM de la Carte-Mère, lue par l'EFI au démarrage. Cette instruction consiste en 6 flags, associés soit à des valeurs 1 (activation) vs 0 (désactivation) qui seront passées au kernel au démarrage. Cette instruction en NVRAM vaut pour toute la machine, c'est-à-dire pour tous les systèmes susceptibles d'être démarrés à partir d'elle et qui sont "sensibles au SIP".
Il suffit (me semble-t-il) qu'une instruction SIP existe dans la NVRAM, quelle que soit sa valeur, pour qu'elle soit respectée, quelles que soient les installations ultérieures d'OS (impliquant le SIP) qu'on fasse - ce qui revient à dire, qu'une fois qu'un choix de l'utilisateur relatif au SIP est établi en NVRAM (ce qui implique nécessairement le niveau logiciel «El Capitan» minimum pour qu'il ait pu être établi) => la vérification de son existence en NVRAM à l'installation ou ré-installation d'un OS impliquant le SIP ne donne pas lieu, en cas de flags du SIP trouvés, à une ré-écriture imposant nécessairement l'activation. C'est seulement si aucun flag du SIP n'est trouvé en NVRAM, que par défaut le SIP s'y trouve activé.
Ta question (qui concerne «Sierra») serait peut-être mieux à sa place ici : ☞Votre avis sur macOS 10.12 Sierra☜ (mais le 2è volet de ma réponse a des implications pour «El Capitan» lui-même).
La réponse est : pareil. Ce resserrement des protocoles de sécurité a l'air bien parti pour durer. Déjà, l'OS «Yosemite 10.10» avait introduit le protocole du kext_signing au démarrage : vérification d'intégrité des extensions Apple. L'OS «El Capitan 10.11» a intégré le kext_signing comme élément d'un verrouillage plus étendu au démarrage : le SIP (System Integrity Protection), qui ajoute un verrouillage de répertoires du Système contre des modifications, une restriction de l'autorité de l'utilisateur root par rapport à ces verrouillages et d'autres limitations touchant la possibilité d'injecter du code. L'OS «Sierra 10.12» reconduit donc le SIP tel quel.
Mais la manipulation du SIP demeure la même que dans «El Capitan». Dans le «Terminal» de l'OS > seule possibilité de s'informer (= lecture) de l'état du SIP par la commande :
Bloc de code:
csrutil status
Bloc de code:
csrutil disable
csrutil enable
csrutil clear--------------------
L'établissement du SIP à l'installation d'un OS qui implique ce protocole («El Capitan» ou «Sierra») comporte néanmoins (me semble-t-il) une "auto-restriction". Mon MacBook Pro Late_2011 a un SSD de 1 To multi-partitionné, avec toute la gamme des OS de «Snow Léopard 10.6» à «Sierra 10.12» sur des partitions séparées (avec les Recovery collatérales à partir de «Lion 10.7»). Or, j'ai désactivé le SIP en permanence depuis mon OS «El Capitan» => à l'install de «Sierra» sur une partition dédiée supplémentaire, aucune réactivation du SIP n'a été effectuée.
Il faut comprendre que le SIP est une instruction inscrite dans la mémoire statique NVRAM de la Carte-Mère, lue par l'EFI au démarrage. Cette instruction consiste en 6 flags, associés soit à des valeurs 1 (activation) vs 0 (désactivation) qui seront passées au kernel au démarrage. Cette instruction en NVRAM vaut pour toute la machine, c'est-à-dire pour tous les systèmes susceptibles d'être démarrés à partir d'elle et qui sont "sensibles au SIP".
Il suffit (me semble-t-il) qu'une instruction SIP existe dans la NVRAM, quelle que soit sa valeur, pour qu'elle soit respectée, quelles que soient les installations ultérieures d'OS (impliquant le SIP) qu'on fasse - ce qui revient à dire, qu'une fois qu'un choix de l'utilisateur relatif au SIP est établi en NVRAM (ce qui implique nécessairement le niveau logiciel «El Capitan» minimum pour qu'il ait pu être établi) => la vérification de son existence en NVRAM à l'installation ou ré-installation d'un OS impliquant le SIP ne donne pas lieu, en cas de flags du SIP trouvés, à une ré-écriture imposant nécessairement l'activation. C'est seulement si aucun flag du SIP n'est trouvé en NVRAM, que par défaut le SIP s'y trouve activé.
--------------------
Dernière édition par un modérateur:
Sujets similaires
macOS Sonoma
Impossible d’ouvrir une application « iOs» car le règlement de sécurité est défini sur « Sécurité moyenne ».
- Membre supprimé 1218279
- macOS