Contrôle du règlement de sécurité du disque de démarrage d’un Mac avec puce Apple
Aperçu
Contrairement aux règlements de sécurité sur un Mac avec processeur Intel, ceux d’un Mac avec puce Apple s’appliquent au niveau de chaque système d’exploitation installé. Cela signifie que plusieurs instances de macOS de versions différentes peuvent bénéficier chacune de leur propre règlement de sécurité sur un même Mac. C’est pour cette raison qu’un sélecteur de système d’exploitation a été ajouté à l’utilitaire Sécurité au démarrage.
Sur un Mac avec puce Apple, l’utilitaire Sécurité système indique l’état de sécurité globale de macOS configuré par l’utilisateur, comme le démarrage d’une extension de noyau ou la configuration de la protection de l’intégrité du système. Si la modification d’un réglage de sécurité réduit considérablement la sécurité du système ou rend ce dernier plus vulnérable, l’utilisateur doit démarrer recoveryOS en maintenant le bouton d’alimentation enfoncé (de sorte qu’aucun logiciel malveillant ne puisse déclencher le signal et que seule une personne physiquement présente puisse procéder) pour procéder à la modification. C’est pourquoi un Mac avec puce Apple ne requiert ni ne prend en charge un mot de passe du programme interne. Toutes les modifications importantes requièrent déjà l’autorisation de l’utilisateur. Pour en savoir plus sur la protection de l’intégrité du système, consultez la rubrique Protection de l’intégrité du système.
Les réglages « Sécurité maximale » et « Sécurité réduite » peuvent être configurés avec l’utilitaire Sécurité au démarrage à partir de recoveryOS. En revanche, le réglage « Sécurité permissive » est accessible uniquement à partir des outils de ligne de commande pour les utilisateurs qui acceptent le risque de réduire considérablement la sécurité de leur Mac.
Règlement Sécurité maximale
« Sécurité maximale » est le réglage par défaut et se comporte comme iOS et iPadOS. Lors du téléchargement du logiciel et de la préparation de son installation, plutôt que d’utiliser la signature globale qui l’accompagne, macOS communique avec le même serveur de signature Apple utilisé par iOS et iPadOS, et demande une nouvelle signature « personnalisée ». Une signature est personnalisée lorsqu’elle inclut l’identifiant unique de puce (ECID, Exclusive Chip Identification), un identifiant unique propre au processeur Apple dans le cas présent, dans le cadre de la demande de signature. Seul ce processeur Apple peut utiliser la signature unique remise par le serveur. Lorsque le règlement Sécurité maximale est actif, la mémoire morte d’amorçage et le LLB contribuent à vérifier qu’une signature donnée n’est pas seulement signée par Apple, mais qu’elle est également signée pour le Mac en question, ce qui lie essentiellement cette version de macOS à ce Mac en particulier.
L’utilisation d’un serveur de signature en ligne fournit également une meilleure protection contre les attaques par retour en arrière par rapport aux signatures globales habituelles. Dans un système de signature globale, l’époque de sécurité pourrait avoir reculé plusieurs fois, mais un système qui n’a jamais vu les programmes internes les plus récents ne le saura pas. Par exemple, un ordinateur qui se croit actuellement à l’époque de sécurité 1 accepte un logiciel provenant de l’époque 2, même s’il se trouve en fait à l’époque 5. Avec le système de signature en ligne de la puce Apple, le serveur de signature peut rejeter la création de signatures pour un logiciel qui n’appartient pas à l’époque de sécurité la plus récente.
De plus, si un assaillant découvre une faille après un changement d’époque de sécurité, il ne peut pas simplement récupérer le logiciel vulnérable d’une époque précédente sur le système A pour l’appliquer au système B afin de l’attaquer. Le fait que le logiciel vulnérable d’une époque antérieure a été personnalisé pour le système A contribue à le rendre non transférable, donc il ne peut pas être utilisé contre le système B. Tous ces mécanismes fonctionnent ensemble pour mieux garantir que les assaillants ne peuvent pas installer un logiciel vulnérable sur un Mac afin de contourner les protections apportées par la plus récente version du logiciel. Cependant, un utilisateur qui a en sa possession le nom d’utilisateur et le mot de passe d’un administrateur pour le Mac peut choisir le règlement de sécurité qui convient à ses besoins.
Règlement Sécurité réduite
Le règlement Sécurité réduite se comporte de façon semblable au règlement Sécurité normale d’un Mac avec processeur Intel et puce T2, où un fournisseur (Apple, dans le cas présent) génère pour le code une signature numérique confirmant qu’il en est à l’origine. Ce comportement contribue à empêcher les assaillants d’insérer un code non signé. Apple qualifie cette signature de « globale », car elle est utilisable pour une durée indéterminée sur n’importe quel Mac réglé sur Sécurité réduite. Le règlement Sécurité réduite ne fournit aucune protection contre les attaques par retour en arrière (bien que les modifications non autorisées du système d’exploitation puissent rendre les données utilisateur inaccessibles). Pour en savoir plus, consultez la section Extensions de noyau sur un Mac avec puce Apple.
En plus de permettre aux utilisateurs d’exécuter des versions antérieures de macOS, le règlement Sécurité réduite est requis pour d’autres actions susceptibles de mettre en danger la sécurité du système de l’utilisateur, comme l’introduction d’extensions de noyau (kexts) tierces. Les extensions de noyau bénéficient des mêmes privilèges que le noyau. Par conséquent, toute vulnérabilité d’une extension de noyau tierce est susceptible de mettre en danger le système d’exploitation dans son ensemble. C’est pourquoi les développeurs sont fortement encouragés à adopter les extensions système, et ce, avant la fin de la prise en charge des extensions de noyau par macOS et les futurs ordinateurs Mac dotés d’une puce Apple. Même lorsque les extensions de noyau tierces sont activées, elles ne peuvent pas être chargées dans le noyau sur demande. Au lieu de cela, elles sont ajoutées à une collection du noyau auxiliaire (AuxKC) dont le hachage est stocké dans le fichier LocalPolicy et qui, par conséquent, requiert un redémarrage. Pour en savoir plus sur la génération d’une AuxKC, consultez la section Extension sécurisée du noyau sous macOS.
Règlement Sécurité permissive
Le règlement Sécurité permissive est destiné aux utilisateurs qui acceptent le risque de soumettre leur Mac à un état considérablement moins sécurisé. Ce mode est différent du mode « Aucune sécurité » d’un Mac avec processeur Intel et puce T2. Grâce au règlement Sécurité permissive, la validation des signatures est tout de même effectuée tout au long de la chaîne de démarrage sécurisé, mais le fait de régler le règlement à « Sécurité permissive » ordonne à iBoot d’accepter les objets de démarrage signés localement par le Secure Enclave, comme une collection du noyau de démarrage généré par l’utilisateur et conçu à partir d’un noyau XNU personnalisé. Ainsi, le règlement Sécurité permissive permet aussi à l’architecture d’exécuter un noyau arbitraire « Système d’exploitation nullement approuvé ». Lorsqu’une collection du noyau de démarrage personnalisée ou un système d’exploitation nullement approuvé est chargé sur le système, certaines clés de déchiffrement deviennent inaccessibles afin d’empêcher tout système d’exploitation nullement approuvé d’accéder aux données des systèmes d’exploitation de confiance.
Important : Apple ne fournit et ne prend en charge aucun noyau XNU personnalisé.
Le règlement Sécurité permissive diffère en un autre point du réglage Aucune sécurité d’un Mac avec processeur Intel et puce T2 : il s’agit d’une condition préalable pour effectuer certaines rétrogradations de sécurité qui étaient auparavant contrôlables de manière indépendante. Tout particulièrement, l’utilisateur doit reconnaître qu’il règle le système à Sécurité permissive pour désactiver la protection de l’intégrité du système sur un Mac avec puce Apple. Cela est nécessaire parce que la désactivation de la protection de l’intégrité du système a toujours rendu le noyau plus vulnérable. En particulier, la désactivation de la protection de l’intégrité du système sur un Mac avec puce Apple désactive l’obligation de signature des extensions de noyau lors de la génération de l’AuxKC, ce qui permet le chargement de toute extension de noyau arbitraire dans la mémoire du noyau. Une autre amélioration a été apportée à la protection de l’intégrité du système sur un Mac avec puce Apple en retirant les règlements de la mémoire vive non volatile et en les plaçant dans le fichier LocalPolicy. Ainsi, la désactivation de la protection de l’intégrité du système requiert l’authentification d’un utilisateur ayant accès à la clé de signature du fichier LocalPolicy à partir de recoveryOS (en maintenant le bouton d’alimentation enfoncé). Il est ainsi beaucoup plus difficile pour un logiciel malveillant, voire pour un assaillant physiquement présent, de désactiver la protection de l’intégrité du système.
Il n’est pas possible de rétrograder le règlement de sécurité à Sécurité permissive à partir de l’utilitaire Sécurité au démarrage. L’utilisateur peut procéder à la rétrogradation uniquement à partir de Terminal dans recoveryOS, à l’aide d’outils de ligne de commande comme csrutil
(pour désactiver la protection de l’intégrité du système). Après que l’utilisateur a procédé à la rétrogradation, la rétrogradation en question est signalée par l’utilitaire Sécurité au démarrage pour permettre à l’utilisateur de facilement régler la sécurité à un règlement plus sécurisé.
Remarque : Un Mac avec puce Apple ne requiert ni ne prend en charge aucune règle de démarrage sur support particulière, car tous les démarrages sont techniquement effectués localement. Si un utilisateur choisit de démarrer à partir d’un support externe, cette version du système d’exploitation doit d’abord être personnalisée au moyen d’un redémarrage authentifié à partir de recoveryOS. Ce redémarrage a pour effet de créer un fichier LocalPolicy sur le disque interne utilisé pour effectuer un démarrage de confiance à partir du système d’exploitation stocké sur le support externe. Cela signifie que la configuration du démarrage à partir du support externe est toujours explicitement activée pour chaque système d’exploitation et requiert dès lors l’autorisation de l’utilisateur. Par conséquent, aucune configuration sécurisée supplémentaire n’est nécessaire.