À propos des Exclaves d’Apple

 (medium.com/@randomaugustine)
1 points par GN⁺ 2025-03-10 | 1 commentaires | Partager sur WhatsApp
  • Les Exclaves d’Apple sont une fonctionnalité d’isolation destinée à conserver certaines ressources sensibles dans une zone séparée même si le noyau XNU est compromis ; la publication du code source de XNU pour les M4 et A18 en a révélé une partie de l’architecture
  • XNU est fondé sur Mach, mais les fonctions système réelles sont concentrées dans le même périmètre de privilèges, ce qui le fait se comporter comme un noyau monolithique ; Exclaves s’inscrit dans une logique de défense en profondeur qui prolonge Secure Enclave, PPL et SPTM
  • Exclaves se compose de domaines et de ressources définis au démarrage, et protège côté XNU, via les nouveaux types de pages de SPTM, des tampons mémoire partagée, des tampons audio, des capteurs, Conclave, des services, etc.
  • Le Secure Kernel (SK) s’exécute sur le même processeur applicatif que XNU ; d’après les indices du code source, il pourrait appartenir à la famille seL4 et utiliser le secure world d’ARM TrustZone, mais une grande partie de son implémentation interne n’est pas publique
  • L’effet réel sur la sécurité dépend des composants déplacés vers Exclaves ; les images de build actuelles indiquent l’utilisation d’indicateurs de sécurité caméra/micro, d’une partie de l’Apple Neural Engine, de certains pilotes et de composants de communication avec Secure Enclave

Noyau monolithique et renforcement de l’isolation chez Apple

  • Les systèmes d’exploitation modernes fonctionnent généralement avec deux domaines de protection : le mode utilisateur et le mode noyau
    • Les applications ne peuvent pas effectuer directement des opérations fortement privilégiées, comme l’accès aux fichiers ou les communications réseau, et doivent les demander au noyau via des appels système
    • Le noyau vérifie les droits d’accès, puis renvoie au mode utilisateur un résultat, par exemple un handle représentant un fichier ouvert
  • La plupart des systèmes d’exploitation utilisent une architecture de noyau monolithique, dans laquelle le noyau dispose de droits d’accès illimités au matériel, à la mémoire et à l’ensemble des données utilisateur
    • Plus le noyau grossit, plus la probabilité d’y voir apparaître des vulnérabilités augmente
    • L’exploitation d’une vulnérabilité du noyau peut conduire à la compromission de tout le système
  • Un micronoyau peut améliorer l’isolation de sécurité en réduisant les fonctions internes du noyau et en repoussant la plupart des tâches vers des processus séparés non privilégiés
    • Les problèmes de performance et l’augmentation de la complexité du logiciel applicatif restent des inconvénients
  • XNU, partagé par iOS, macOS, tvOS, visionOS et watchOS, repose sur le micronoyau Mach, mais dans son implémentation, de nombreuses fonctions système se trouvent dans le même périmètre de privilèges, ce qui le fait en pratique se comporter comme un noyau monolithique

L’isolation de sécurité d’Apple avant Exclaves

  • En 2013, l’iPhone 5s a introduit Secure Enclave
    • Un OS fondé sur un micronoyau, appelé SepOS, s’exécute sur un cœur CPU renforcé dédié
    • Le noyau de SepOS est cL4, une version personnalisée par Apple de L4-embedded
    • Il sert à protéger les clés cryptographiques et les données biométriques comme Face ID
    • Même si le noyau iOS est compromis, Secure Enclave n’est généralement pas affecté sans exploit supplémentaire la ciblant spécifiquement
    • Secure Enclave et Secure Exclaves sont des cibles différentes
  • En 2017, les iPhone 8 et iPhone X basés sur A11 ont introduit la Page Protection Layer (PPL)
    • Elle ne donne le droit de modifier les tables de pages mémoire qu’à une partie du noyau, et empêche le reste du noyau de les modifier directement
    • Sa surface d’attaque étant réduite, les contournements étaient rares, mais le reste du noyau conservait toujours de nombreux privilèges nécessaires à une compromission des données
  • Entre 2021 et 2023, avec A15 et iOS 17, le Secure Page Table Monitor (SPTM) a remplacé et amélioré PPL
    • Il protège des fonctionnalités mémoire supplémentaires et isole de petits composants du noyau
    • La vérification de signature de code, qui contrôle si le code est signé par Apple, a également été séparée
    • À cette période, des références indirectes à exclaves sont apparues dans le code source de XNU ; elles étaient alors supposées désigner un sous-système géré par SPTM

L’arrivée des Exclaves de XNU en 2024

  • La publication du code source de XNU prenant en charge les systèmes basés sur M4 et A18 a révélé une partie de l’architecture des Exclaves
    • Des systèmes comme l’iPhone 16 sont concernés
    • Exclaves n’est pas activé sur les processeurs antérieurs
  • Exclaves désigne des ressources séparées de XNU, conçues comme une zone protégée même en cas de compromission du noyau
    • Les ressources sont prédéfinies lors du build de l’OS
    • Elles sont identifiées par nom ou par ID
    • Elles possèdent un type et sont initialisées au démarrage
    • Elles sont organisées en domaines distincts
  • SPTM protège la mémoire Exclave de XNU au moyen d’un type de page dédié à Exclave
  • Les types de ressources identifiés montrent où se situe la frontière entre XNU et Exclave
    • Des tampons mémoire partagée accessibles à la fois par XNU et par Exclave
      • Du point de vue de XNU, ils peuvent être configurés en lecture seule ou en lecture-écriture
    • Des tampons audio et des capteurs utilisés pour sécuriser des fonctions comme les indicateurs d’accès caméra/micro
    • Conclave et Conclave Manager, qui regroupent plusieurs ressources dans leur propre domaine de sécurité
    • Des services permettant d’exécuter du code dans l’espace Exclave lorsqu’ils sont appelés par un thread XNU

Secure Kernel et secure world

  • Pour que les services Exclave s’exécutent isolés de XNU, Apple a introduit le Secure Kernel (SK)
  • Le fichier image de SK contient une chaîne de version « cL4 »
    • La structure IPC semble plus proche de seL4 que du L4-embedded du cL4 original de SepOS
    • Les chaînes de SK font souvent apparaître des termes de la famille seL4, comme capability, frame, untyped memory ou minting
    • Apple a annoncé en avril 2024 son adhésion à la seL4 Foundation
  • Contrairement à SepOS, qui s’exécute sur un processeur dédié, SK s’exécute sur le même processeur applicatif haute performance que XNU/iOS
  • Cette architecture nécessite un niveau de privilège processeur supplémentaire ; parmi les bases possibles figurent les extensions de virtualisation, des fonctions supplémentaires du SPTM d’Apple et TrustZone d’ARM
    • Le code source de XNU contient des références liées au passage vers le secure world de TrustZone
    • L’architecture peut être interprétée comme XNU et iOS fonctionnant dans l’insecure world, et SK dans le secure world
  • SK fournit un environnement d’exécution limité aux Exclave, ressources et services
    • Il diffère du modèle de conception des Trusted Applications proposé par ARM
    • La surface d’attaque des services Exclave et du Secure Kernel étant limitée, il est probablement bien plus difficile de sortir du secure world pour compromettre XNU que d’attaquer directement XNU depuis l’insecure world
  • Dans le code source de XNU, le passage au secure world est désigné par RINGGATE
    • L’idée que SPTM puisse gérer cette transition reste une hypothèse ; les zones concernées ne sont pas open source et nécessitent une analyse binaire

Domaines, ressources et Conclave

  • Pendant le démarrage, XNU initialise une structure de tables noyau à deux niveaux pour contenir les informations sur les ressources Exclave découvertes
    • root_table identifie les domaines par leur nom
    • Chaque domaine référence une table de second niveau contenant les ressources de ce domaine
  • La structure de domaines identifiée est la suivante
    • com.apple.kernel
      • Contient notamment le lanceur de Conclave, des services de debug, ExclaveIndicatorController pour les voyants de sécurité, un service de logs et FrameMint utilisé au démarrage d’ExclaveKit
      • Contient également le tampon mémoire partagée com.apple.storage.backend, utilisé par les services Exclave pour effectuer des I/O fichier dans l’espace XNU via des upcalls
      • Contient les ressources Conclave Manager, une par Conclave
    • com.apple.darwin
      • Aucun cas d’usage n’apparaît dans les composants open source
    • com.apple.conclave.name
      • Il existe un domaine par Conclave
      • Il peut contenir des services, des tampons audio, des tampons mémoire partagée, etc.
    • com.apple.driver.*name*
      • Son existence est mentionnée comme domaine propre à chaque pilote de périphérique sur la base de commentaires, mais elle n’est pas réellement confirmée dans le code open source
  • Conclave est à la fois un type de ressource pouvant contenir plusieurs ressources, et une unité de sécurité permettant aux services et ressources de partager des accès entre eux
    • Les Conclaves appelables par une Mach task sont limités
    • Chaque Conclave dispose d’un Conclave Manager situé dans le domaine kernel
    • Un Conclave possède un cycle de vie avec attach, launch, stop, detach
    • Il existe aussi des états de transition comme launching et stopping

Création, connexion et exécution d’un Conclave

  • posix_spawn() de XNU peut appeler task_add_conclave() pour connecter une task à une ressource Conclave Manager
    • La relation est de 1:1
    • Une task n’est connectée qu’à un seul Conclave Manager, et l’inverse est également vrai
  • Les entités pouvant spawn un Conclave sont launchd ou une task disposant de l’entitlement com.apple.private.exclaves.conclave-spawn
    • L’entitlement com.apple.private.exclaves.conclave-host s’interprète plutôt comme le droit de s’attacher soi-même, plutôt que de spawn une nouvelle task
  • Le noyau recherche dans le domaine com.apple.kernel la ressource Conclave Manager connectée au Conclave cible
    • Il stocke ensuite dans la structure de ressource Conclave un endpoint Tightbeam pointant vers l’endpoint du Conclave Manager
    • Tightbeam semble être un framework RPC destiné à la communication entre composants Exclave
  • L’exécution du Conclave doit être effectuée depuis la task Conclave Manager connectée
    • Les tentatives de launch attendent que les Exclaves aient complètement démarré jusqu’à l’état EXCLAVES_BS_BOOTED_EXCLAVEKIT
    • Le nouveau Mach trap arrive dans la fonction _exclaves_ctl_trap(), et EXCLAVES_CTL_OP_LAUNCH_CONCLAVE est utilisé pour l’exécution du Conclave
    • En environnement de production, un host Conclave lancé peut passer dans un état tainted, et un exit() ultérieur peut provoquer un kernel panic

Nouveau Mach trap pour Exclaves

  • _exclaves_ctl_trap() est un nouveau Mach trap qui traite les fonctionnalités Exclave
    • Il effectue différentes actions selon le paramètre operation
    • En général, il vérifie l’entitlement requis pour l’operation appelée
  • EXCLAVES_CTL_OP_BOOT est appelé deux fois pendant le démarrage du système
    • Démarrage de l’étape 2 du boot Exclaves
    • Démarrage d’ExclaveKit
    • L’appelant doit être launchd ou posséder l’entitlement com.apple.private.exclaves.boot
  • Les autres operations principales exigent au minimum que la task courante possède l’entitlement com.apple.private.exclaves.kernel-domain ou qu’elle soit la task Conclave Manager concernée
    • EXCLAVES_CTL_OP_LOOKUP_SERVICES : recherche des services dans le domaine Exclave de la task courante, puis, en cas d’échec, vérifie les domaines Darwin et kernel selon les droits
    • EXCLAVES_CTL_OP_ENDPOINT_CALL : appelle l’endpoint d’un service Exclave dans le domaine de la task courante, faisant passer le thread courant dans le secure world pour exécuter du code spécifique
    • Création de named buffer et copyin/copyout
    • Création d’audio buffer et copyout
    • Création, start, stop et status de sensor
    • Recherche de notification resource

Downcall et Upcall

  • Un Downcall est un appel d’endpoint de service Exclave situé dans le secure world ; c’est le point où commence l’exécution de code dans le secure world
  • Un Downcall fait passer le thread courant dans le secure world et lance l’exécution au point d’entrée du code sécurisé
    • Ce n’est pas un modèle où le travail est délégué à un autre thread
    • La task appelante doit posséder l’entitlement kernel domain ou être la task Conclave Manager connectée au Conclave du service concerné
    • Un Conclave peut contenir jusqu’à 128 services appelables
  • XNU semble planifier le thread dans le Secure Kernel via sk_enter()
    • Il est possible que SK ne possède pas de threads indépendants et que XNU gère toute la planification des threads du secure world
    • Un thread en cours d’exécution dans le secure world peut effectuer des opérations classiques de scheduler comme yield, wait, suspend ou interrupt
    • Dans ce cas, le thread quitte le secure world, revient dans le contexte du noyau XNU, puis est replanifié dans le secure world par le code de scheduling Exclave
  • La structure IPC du Downcall est configurée avec des tampons request/response avant l’entrée dans le secure world
    • Les interruptions et la préemption sont désactivées pendant la préparation de la structure IPC request finale et l’appel à sk_enter()
    • C’est parce que cette structure n’existe qu’à un seul exemplaire par cœur CPU
    • La réponse au Downcall peut revenir dans le tampon de réponse per-core d’un autre CPU en raison d’une interruption, d’un upcall, d’un yield ou d’une replanification
  • Un Upcall est le mécanisme par lequel un thread exécuté dans le secure world appelle, via Tightbeam, un handler d’upcall Exclaves lorsqu’il a besoin de l’aide de XNU
    • Il est limité à certaines fonctions XNU autorisées
    • Un thread en upcall ne peut pas revenir en mode utilisateur
    • Il n’est pas non plus autorisé à réentrer via un downcall vers le secure world
    • Le thread doit revenir au contexte secure world depuis lequel l’upcall a été effectué
  • Les catégories d’upcall identifiées dans le code source sont la mémoire, le stockage fichier, DriverKit, DriverKit Apple Neural Engine et le contrôle de Conclave

XNUProxy et étapes de démarrage

  • Les références à XNUProxy sont nombreuses, mais son emplacement et son rôle exacts ne sont pas confirmés
    • Il pourrait s’agir d’un domaine Exclave indépendant
    • Il pourrait s’agir d’un service, ou d’un ensemble de services, traitant certains downcalls dans le domaine com.apple.kernel
    • Il pourrait aussi s’agir d’un sous-système SPTM effectuant des downcalls vers le secure world
  • Les commentaires de Exclaves_L4.h indiquent que XNU Proxy rend plusieurs Exclave accessibles
    • user app template
    • audio driver
    • ExclaveDriverKit
    • SecureRTBuddy pour Always On Processor et Display Coprocessor
    • Conclave control, Conclave debug, etc.
  • Le démarrage d’Exclaves nécessite une coordination entre insecure world et secure world, et en cas de problème il conduit généralement à un panic()
  • Le démarrage est divisé en trois étapes
    • La Stage 1 n’apparaît pas dans l’open source ; elle pourrait correspondre au processus de secure boot qui charge SK en mémoire, vérifie la signature de code, puis le rend exécutable
    • La Stage 2 initialise le serveur d’upcall, collecte les informations de démarrage du secure kernel, initialise le scheduler Exclave, initialise le kext XrtHostedXNU, initialise le multicœur, initialise XNU Proxy, découvre les ressources Exclave statiques, crée les endpoints Conclave Manager, etc.
    • La Stage 3 recherche le service com.apple.service.FrameMint, effectue les appels liés à framemint_framemint__init() et framemint_framemint_populate(), puis atteint l’état EXCLAVES_BS_BOOTED_EXCLAVEKIT

Types mémoire SPTM et limites restantes

  • SPTM attribue un type aux pages mémoire afin de contrôler l’accès par sous-système
    • Les types existants incluent XNU_USER_EXEC, XNU_USER_DEBUG, XNU_USER_JIT, XNU_ROZONE, XNU_KERNEL_RESTRICTED, ainsi que des types liés à TXM et DART
  • Exclaves ajoute de nouveaux types liés à SK
    • SK_DEFAULT : réservé à SK, inaccessible à XNU
    • SK_IO : réservé à SK, inaccessible à XNU
    • SK_SHARED_RO : partagé entre SK et XNU, mais XNU est en lecture seule
    • SK_SHARED_RW : partagé entre SK et XNU, avec accès lecture-écriture pour XNU
  • Exclaves peut être vu comme un investissement important pour ajouter de la défense en profondeur aux systèmes d’exploitation Apple
    • Il isole les ressources sensibles et réduit la surface d’attaque potentielle
    • Il va dans le sens d’une réduction de l’impact d’une compromission unique du noyau
  • Les composants effectivement déplacés du noyau vers Exclaves n’ont pas été analysés directement
    • Les images de build indiquent l’usage d’indicateurs de sécurité caméra/micro, de certaines fonctionnalités de l’Apple Neural Engine, de certains pilotes de périphériques et de composants communiquant avec Secure Enclave
    • Davantage de composants pourraient être déplacés vers Exclaves à l’avenir
    • Les zones de XNU extérieures à Exclaves restent des cibles d’attaque
  • L’analyse repose sur Apple Open Source XNU build 11215
    • L’emplacement exact d’ExclaveKit, ExclaveDriverKit et XNUProxy, la manière dont XNU bascule vers le secure world, le Secure Kernel et le userspace du secure world restent des domaines nécessitant une analyse supplémentaire

À lire aussi

1 commentaires

 
GN⁺ 2025-03-10
Avis sur Hacker News

  • Les SoC récents des téléphones et ordinateurs portables d’Apple intègrent une prise en charge matérielle de la virtualisation imbriquée, y compris l’iPad Pro M4 qui utilise une exclave pour la LED de la caméra.
    J’espère que la prochaine révision du guide Apple Platform Security couvrira l’exclave SK et les mesures d’atténuation côté baseband pour la détection radar Wi‑Fi : https://help.apple.com/pdf/security/en_US/apple-platform-sec...
    Il existe aussi un article de rétro-ingénierie de SPTM sur les fonctionnalités supplémentaires du SPTM d’Apple : https://www.df-f.com/blog/sptm3
    XNU est en cours de refactorisation vers une architecture inspirée des microkernels, avec l’objectif de réduire la base de code et de déplacer à l’extérieur les tâches sensibles en matière de sécurité. L’isolation des espaces mémoire est aidée par le Secure Page Table Monitor (SPTM), tandis que des opérations comme la signature de code, la vérification des autorisations, le Developer Mode et le Restricted Execution Mode sont prises en charge par le Trusted eXecution Monitor (TXM).
    Il existe plus de 150 CVE liés à TrustZone : https://www.cve.org/CVERecord/SearchResults?query=trustzone
    Google a également implémenté il y a quelques années pKVM sur les Pixel, qui utilise la virtualisation imbriquée matérielle, et a même fait intégrer dans le noyau Linux principal du code qui abaisse de manière coopérative les privilèges de TrustZone par rapport au niveau L0 de pKVM. En revanche, à part la VM Debian « Linux Terminal », l’entreprise n’a pas annoncé de fonctionnalité défensive exploitant pKVM/AVF.

    • La plupart des CVE TrustZone concernent des logiciels vulnérables que les fabricants ont placés dans l’environnement protégé par TrustZone. Parmi ces logiciels, beaucoup sont franchement médiocres, et les rapports de vulnérabilités concernant le matériel lui-même sont très rares.
    • L’auteur a publié un article de suivi et un diagramme corrigé : https://randomaugustine.medium.com/more-speculation-on-excla...
      Au départ, il supposait une utilisation de TrustZone, mais il semble que l’exclave pourrait aussi utiliser le SPTM existant et le niveau de privilège GXF (Guarded Execution). Dans ce cas, en dehors des besoins en RAM et de l’effort de développement, il n’y aurait peut-être pas de raison fondamentale empêchant une prise en charge à partir de l’iPhone 13. Bien sûr, cela resterait évidemment un travail énorme, même pour Apple.

  • Steve semblait sincèrement croire qu’un « ordinateur portable est le journal intime d’une personne » et qu’Apple avait la responsabilité de le protéger.
    Je pense que Tim ne serait pas devenu CEO s’il n’avait pas partagé la même conviction que Steve. Ça peut paraître étrange, mais Steve me manque vraiment.
    https://www.youtube.com/watch?v=Ij-jlF98SzA

    • Du point de vue de quelqu’un qui fabrique des équipements industriels et scientifiques, les appareils grand public d’Apple sont totalement inutiles. Verrouiller ainsi des dispositifs informatiques pourtant tout à fait capables paraît être un gâchis.
      Je n’aime pas non plus la façon dont Apple contrôle l’appareil et le marché logiciel même après un changement de propriétaire. J’évite soigneusement ce type d’écosystème, et je ne comprends pas pourquoi tant de soi-disant « hackers » s’enthousiasment pour des systèmes dont le capot a été soudé fermé.
    • Jobs était clivant et souvent cassant, et on peut se demander pourquoi il faudrait regretter un milliardaire de la tech au départ. Malgré tout, j’ai le sentiment d’avoir une dette envers Jobs et les gens d’Apple qui ont contribué à créer des produits que j’aime, comme le Mac, l’iPod ou l’iPad.
      Beaucoup de choses que Jobs a dites résonnent encore aujourd’hui. Apple a récemment sorti un économiseur d’écran « classic Mac », qui montre à quel point l’interface graphique originale du Mac avait été conçue avec soin. Personne ne regrette l’époque où un bug d’application pouvait faire tomber tout le système d’exploitation, mais j’aimerais qu’Apple soit encore aujourd’hui aussi obsédée par les détails qu’à l’époque.
    • En voyant les sentiments sincères à l’égard de Jobs, je me demande si quelque chose de similaire est à l’œuvre quand les gens utilisent et expérimentent les LLM.
      Pour le dire un peu crûment, il semble y avoir là un élément mystique ou religieux. Comme le désir ardent d’un homme bienveillant, presque divin, qui apporterait des miracles, des oracles, de beaux produits et rituels, ainsi qu’un avenir lisse, abondant et éternel. Comme si une sorte de « trou » spirituel était comblé.
      Je ne cherche pas à rabaisser les personnes qui apprécient Jobs ou les LLM ; je partage simplement une observation.
    • Je comprends que l’article sur les exclaves ait fait penser à Steve, mais je ne vois pas très bien comment l’un mène à l’autre. Pourrais-tu l’expliquer ?

  • Fil lié : « Apple rearranged its XNU kernel with exclaves » https://news.ycombinator.com/item?id=43314171

    • D’après le résumé de cet article, une exclave désigne des ressources spécifiques séparées de XNU, le noyau principal, et inaccessibles même si le noyau est compromis.
      Il explique aussi qu’il n’est pas rare que des fonctionnalités préparant la prochaine version majeure apparaissent dans une version intermédiaire de macOS, et que les exclaves pourraient être la fonctionnalité la plus fondamentale et la plus importante ajoutée à Sonoma 14.4, iOS 17.4, iPadOS 17.4 et watchOS 10.4.
      https://eclecticlight.co/2024/08/20/sonomas-unfinished-busin...

  • Utiliser une exclave de sécurité pour contrôler la LED physique de la caméra est assez surprenant, et cela donne l’impression d’une conception excessivement complexe pour une tâche simple.
    Il aurait sans doute suffi d’ajouter une toute petite logique matérielle dédiée dans le module caméra. Il suffit de verrouiller les entrées/sorties numériques ou l’alimentation de la caméra, et d’ajouter un allongeur d’impulsion pour que la LED reste allumée au moins quelques secondes à chaque fois, afin d’empêcher les attaques consistant à allumer et éteindre rapidement la logique de la caméra.
    Ce serait bien d’avoir un circuit similaire pour le micro, avec une LED physique d’une couleur distincte. Un simple point affiché par logiciel à l’écran ne suffit pas.

    • C’est plus complexe qu’il n’y paraît. Une « caméra » est un ensemble de plusieurs composants. On pourrait vouloir se baser sur l’alimentation du capteur CMOS, mais il existe plusieurs états d’alimentation, comme veille, économie d’énergie ou inactivité. Un circuit matériel devrait donc très probablement connaître non seulement la tension, mais aussi le courant. Ou bien il faudrait peut-être remonter d’un niveau et analyser des messages comme ceux en I2C pour lire les changements de mode d’alimentation.
      Le pilote de LED doit aussi connaître la luminosité de l’écran ou les informations du capteur de lumière ambiante. Elle doit être assez lumineuse pour rester visible en plein soleil, mais cette luminosité peut être désagréable dans un environnement sombre et gêner l’utilisation normale de la caméra.
      Si l’on croit que le SK est sûr, l’utiliser est à la fois plus simple et plus efficace. Si l’on considère que le SK n’est pas sûr, alors toutes les hypothèses s’effondrent de toute façon.
    • Ce n’est pas une conception excessive. C’est nécessaire à cause de ce type de recherche et des résultats d’autres chercheurs comme Charlie Miller.
      Apple ne rend généralement pas les choses volontairement complexes sans bonne raison.
      https://news.ycombinator.com/item?id=42260379
    • Je me demande si c’est une conception excessive, ou si c’est une solution à quelque chose qu’Apple a découvert en livrant des quantités énormes de téléphones. Je n’aurais pas pensé à la caméra comme vecteur de sécurité, mais Apple la voit peut-être ainsi.
    • Le contexte connexe est détaillé davantage ici : https://news.ycombinator.com/item?id=42260379
    • Il ne s’agit probablement pas seulement de la LED de la caméra, mais aussi des indicateurs à l’écran, comme les points orange, vert et bleu qui apparaissent dans la barre de menus lorsqu’une app accède au micro, à la caméra ou à l’enregistrement de l’écran.

  • Je me demande qui est l’auteur de cet article. C’est un texte très précis et bien écrit, et même pour quelqu’un qui suivait les exclaves, il résume très bien le sujet.

  • Je me demande comment cela se compare à la Virtualization Based Security de Linux.
    D’après la page contenant la vidéo, cette fonction de sécurité peut renforcer le noyau et garantir que des ressources critiques du noyau ne puissent pas être altérées même si le noyau est compromis. VBS utilise la virtualisation matérielle et l’hyperviseur Hyper‑V pour créer un environnement virtuel isolé fonctionnant à un niveau de confiance plus élevé, le Virtual Trust Level 1 (VTL1), et VTL1 dispose de son propre noyau, séparé du noyau invité, appelé Secure Kernel.
    https://lssna24.sched.com/event/1aIeD/linux-virtualization-b...

    • Une Exclave s’exécute à un niveau de confiance parallèle.

  • Les Exclaves sont importantes, mais elles ressemblent à une étape intermédiaire. Apple rend XNU moins risqué, mais avance encore de manière défensive plutôt que d’adopter pleinement une architecture micro-noyau.
    Si je devais parier, les exclaves seraient un pont vers un changement plus vaste. Peut-être un système d’exploitation plus modulaire comme Fuchsia, ou un modèle de sécurité à la CHERI imposant la sûreté mémoire au niveau matériel.
    Apple est en avance en matière de sécurité des systèmes d’exploitation grand public, mais les exclaves ressemblent davantage à une amélioration par patchwork qu’au résultat d’une refonte complète de la conception système. Cela dit, c’est probablement le plus grand changement de sécurité dans la conception des systèmes d’exploitation grand public de ces dix dernières années, et il faudra plusieurs années avant d’en voir tous les effets.

    • Cela ressemble à un retour à l’ancien modèle micro-noyau, mais sous une forme tenant compte des solutions modernes et des nouvelles exigences.
      Quand Mach a été créé, la sécurité n’était pas une préoccupation aussi importante qu’aujourd’hui. Les machines actuelles sont si performantes que le surcoût lié à la communication interprocessus d’un micro-noyau est peut-être devenu négligeable.

  • Je ne suis pas familier avec du contenu de ce niveau, mais à première vue, il semble possible d’attaquer l’enclave elle-même pour obtenir des privilèges supérieurs à ceux du noyau. Je me demande si ce morceau de matériel est une sorte de coprocesseur.

    • Une Exclave n’est pas du matériel, mais un logiciel isolé qui traite certaines opérations sensibles auxquelles le noyau ne doit pas pouvoir accéder.
      Donc, si on l’exploite, on obtient bien des droits d’accès que le noyau n’a pas. Mais c’est précisément l’objectif. Le but est que, même si le noyau est compromis, il ne puisse pas accéder à cette zone sensible.

  • D’après la documentation d’Apple, SPTM n’est pas utilisé ; je me demande donc quel impact cela aura sur la sécurité de macOS : https://support.apple.com/guide/security/operating-system-in...
    Pour l’instant, des exclaves existantes comme celles qui affichent l’indicateur de caméra ne semblent pas vraiment s’appliquer à macOS, puisque les MacBook disposent d’un matériel dédié. Mais à l’avenir, il pourrait y avoir des exclaves qui s’appliquent aussi à macOS.

    • Il faut relire cette note de bas de page. Elle indique que la Page Protection Layer (PPL) et le Secure Page Table Monitor (SPTM) imposent l’exécution de code signé et approuvé sur toutes les plateformes sauf macOS. C’est parce que macOS est conçu pour exécuter du code arbitraire. Les autres propriétés de sécurité, y compris la protection des tables de pages, existent sur toutes les plateformes prises en charge.
      Autrement dit, cela ne signifie pas que macOS n’utilise pas SPTM. Cela signifie que macOS n’utilise pas SPTM pour empêcher l’exécution de code non signé. macOS doit permettre aux utilisateurs d’exécuter du code non signé après quelques étapes.

  • Je me demande si les développeurs d’apps peuvent utiliser les Exclaves. Ce qui est frustrant, c’est qu’Apple crée en interne de nouvelles fonctionnalités étonnantes, puis les bloque complètement aux développeurs. Résultat, les apps bancaires, les portefeuilles et les messageries sécurisées doivent continuer à tourner dans un espace utilisateur moins sécurisé

    • Pas forcément. L’espace utilisateur d’Apple est lui aussi devenu de plus en plus sûr
      Un exemple simple : les versions récentes de macOS exécutent toutes les apps dans une sandbox, même si l’app ne l’a pas explicitement choisi. Cette sandbox empêche les apps de modifier les fichiers des autres, ce qui était auparavant une grosse faiblesse du système de sécurité. La signature des bundles n’était en effet vérifiée qu’au premier lancement, et pas à chaque exécution
    • D’après ce que je comprends, ce n’est pas possible avec la conception actuelle. Les Exclaves sont intégrées à l’ensemble du système d’exploitation et démarrent dans le cadre du processus de boot, elles sont donc relativement statiques. Pour des raisons de sécurité, il est probable que les relations entre ces composants soient elles aussi définies statiquement
      Pour l’instant, c’est aussi une architecture noyau à noyau ; s’il y avait un support tiers, il serait probablement limité à des cas comme l’implémentation de pilotes de périphériques de sécurité. Mais Apple a cherché à pousser les pilotes tiers vers l’espace utilisateur plutôt que vers l’hyperviseur. Vu que cette transition se fait en parallèle du développement des exclaves, il ne semble pas probable qu’Apple s’oriente vers une utilisation des exclaves par les développeurs de pilotes tiers
      Il est courant qu’Apple stabilise bien davantage en interne ce type de fonctionnalité de plateforme imposée au niveau du noyau avant de l’ouvrir à l’extérieur. L’authentification de pointeurs d’arm64e en est un exemple similaire
    • Pas pour l’instant