# Pièges sémantiques dans les noms de fichiers : la conception de la sécurité de macOS sous l'angle des relations d'équivalence

Introduction

Qu’est-ce que l’« identité » ?

Cette question, d’apparence simple, est truffée de pièges dans les systèmes informatiques. En avril 2025, Linus Torvalds a publié un e-mail cinglant sur la liste de diffusion du noyau Linux concernant la fonctionnalité de case-folding (pliage de casse) de bcachefs¹. Son argument central peut se résumer en une phrase : les noms de fichiers ne devraient être qu’une simple suite d’octets, et le système de fichiers ne devrait pas tenter de les « comprendre ».

Il ne s’agit pas seulement d’une question de préférence technique. Dès que nous commençons à donner une sémantique aux noms de fichiers — par exemple, en demandant au système de comprendre que « A » et « a » sont identiques, ou que « é » et « e+´ » sont équivalents — nous ouvrons une boîte de Pandore.

Tentons de comprendre l’essence de ce problème.

L’essence des noms de fichiers : identifiant ou nom ?

Dans une bibliothèque, chaque livre possède deux modes d’identification : son titre et sa cote. Le titre a une sémantique, il vous indique le sujet du livre ; la cote est opaque, c’est simplement un identifiant unique utilisé pour localiser le livre sur l’étagère.

Les concepteurs d’Unix ont choisi le modèle de la « cote ».

Dans la philosophie de conception d’Unix, un nom de fichier est une séquence d’octets opaque. La responsabilité du noyau est simple : mapper cette séquence d’octets à un inode (nœud d’index). Comme l’indique l’ouvrage « Understanding the Linux Kernel » publié par O’Reilly : « Un fichier Unix est un conteneur d’informations structuré comme une séquence d’octets ; le noyau n’interprète pas le contenu d’un fichier. »² Cette philosophie de « non-interprétation » s’applique également aux noms de fichiers.

Quelle est la raison profonde de ce choix de conception ?

La simplicité apporte la prévisibilité. Lorsque les noms de fichiers ne sont que des séquences d’octets, le comportement du système est totalement déterministe : deux noms de fichiers sont identiques si et seulement si leurs séquences d’octets sont strictement identiques. Pas d’ambiguïté, pas de cas particuliers, pas de dépendance culturelle. La couche VFS (Virtual File System) résout le chemin en inode via le cache d’entrées de répertoire (dentry cache), mais ce processus est une pure comparaison d’octets³.

Cependant, macOS a choisi une voie différente.

Relations d’équivalence : quand l’identité devient complexe

En mathématiques, une relation d’équivalence est une relation qui satisfait trois propriétés : la réflexivité (a ~ a), la symétrie (si a ~ b, alors b ~ a) et la transitivité (si a ~ b et b ~ c, alors a ~ c). Lorsque nous disons qu’un système est insensible à la casse, nous définissons en réalité une relation d’équivalence : A ~ a, B ~ b, et ainsi de suite.

Cela semble simple, n’est-ce pas ?

Mais le problème est le suivant : qui définit cette relation d’équivalence ? Différents systèmes peuvent avoir des définitions divergentes.

En anglais, la majuscule de « i » est « I », ce qui semble évident. Mais la langue turque possède quatre variantes du « i » :

En turc, la majuscule de « i » est « İ » (I majuscule avec point), tandis que la minuscule de « I » est « ı » (i minuscule sans point)⁴. Cela signifie que si un contrôle de sécurité utilise les règles anglaises pour convertir « FILE » en minuscules et obtient « file », alors que le système de fichiers utilise les règles turques et obtient « fıle », les deux chaînes ne correspondront pas — même si elles « devraient » représenter le même nom de fichier.

Cela révèle un problème profond : la conversion de casse n’est pas une opération universelle et indépendante de la culture. Lorsque nous implémentons l’insensibilité à la casse au niveau du système de fichiers, nous devons choisir une règle spécifique — et ce choix peut être en contradiction avec les règles utilisées par les programmes de l’espace utilisateur.

Normalisation Unicode : un terrier de lapin encore plus profond

Si l’insensibilité à la casse est déjà complexe, la normalisation Unicode pousse le problème dans une autre dimension.

Commençons par une question simple : « é » est-il un seul caractère ou deux ?

En Unicode, la réponse est « les deux ». « é » peut être représenté par un point de code unique U+00E9 (LATIN SMALL LETTER E WITH ACUTE), ou par deux points de code U+0065 (LATIN SMALL LETTER E) + U+0301 (COMBINING ACUTE ACCENT). Ces deux représentations sont visuellement identiques, mais strictement différentes au niveau des octets :

1
Forme précomposée (NFC) : C3 A9           -> é
2
Forme décomposée (NFD) :  65 CC 81        -> e + ́ → é

Le standard Unicode définit quatre formes de normalisation : NFC, NFD, NFKC et NFKD⁶. La forme NFC privilégie les caractères précomposés, tandis que la forme NFD privilégie la décomposition des caractères en un caractère de base suivi de marques de combinaison.

HFS+ a choisi la forme NFD. Selon la documentation technique d’Apple, HFS+ utilise une forme de normalisation « très proche de la forme de normalisation Unicode D »⁷. Cela signifie que lorsque vous créez un fichier nommé café, le système décompose automatiquement le é en deux points de code e + ´.

Cette décision de conception a sa logique : en imposant la normalisation, HFS+ garantit qu’un même « caractère » n’a qu’une seule représentation, évitant ainsi que l’utilisateur ne crée deux fichiers qui « semblent identiques mais sont en réalité différents ».

Mais il y a un problème majeur : les règles de normalisation de HFS+ sont basées sur Unicode 3.2, et ces règles ne peuvent plus être mises à jour avec l’évolution du standard Unicode, car « une telle évolution invaliderait les volumes HFS+ existants »⁸.

En 2017, Apple a lancé APFS pour remplacer HFS+. APFS a apporté un changement important : il n’impose plus la normalisation Unicode, mais il est normalization-preserving but normalization-insensitive (respectueux de la normalisation mais insensible à celle-ci)⁹. Cela signifie qu’APFS conserve la séquence d’octets originale que vous avez saisie, tout en tenant compte de l’équivalence de normalisation lors de la comparaison des noms de fichiers.

Ce changement résout certains problèmes, mais en crée de nouveaux. Lors de la migration de HFS+ vers APFS, les noms de fichiers initialement normalisés conservent leur forme NFD, tandis que les nouveaux fichiers créés peuvent utiliser la forme NFC. Dans certains cas limites, cela peut conduire à la coexistence de noms de fichiers « visuellement identiques mais réellement différents » dans le même répertoire.

L’essence des failles de sécurité : l’incohérence des relations d’équivalence

Nous pouvons maintenant comprendre l’essence des failles de sécurité.

Lorsqu’un programme de contrôle de sécurité et le système de fichiers utilisent des relations d’équivalence différentes, un « interstice » se crée. Un attaquant peut construire un nom de fichier qui semble sûr pour le programme de contrôle, mais qui est équivalent à un nom de fichier dangereux pour le système de fichiers.

Torvalds a décrit ce problème avec précision dans son e-mail :

Security issues like “user space checked that the filename didn’t match some security-sensitive pattern”. And then the shit-for-brains filesystem ends up matching that pattern anyway…

Voyons un exemple concret.

En mars 2021, le projet Git a divulgué une vulnérabilité critique CVE-2021-21300¹⁰. Cette faille affectait particulièrement les utilisateurs de Windows et macOS utilisant des systèmes de fichiers insensibles à la casse.

Le principe de la faille repose sur le mécanisme de cache lstat de Git. Lorsque Git extrait des fichiers, il maintient un cache pour réduire les appels système. Un attaquant peut construire un dépôt malveillant contenant deux fichiers : A et a. Sur un système de fichiers sensible à la casse, ce sont deux fichiers distincts ; mais sur un système insensible à la casse, ils entrent en conflit.

La clé de l’attaque réside dans l’incohérence entre la logique interne de Git (basée sur l’hypothèse de la sensibilité à la casse) et le comportement du système de fichiers (insensible à la casse). L’attaquant exploite cette divergence pour permettre à Git d’exécuter du code arbitraire pendant le processus d’extraction.

Les problèmes de sécurité liés à la normalisation Unicode sont encore plus subtils. Selon l’article de recherche de Black Hat USA 2019 intitulé « Host/Split: Exploitable Antipatterns in Unicode Normalization », lorsque des décisions de sécurité sont basées sur des chaînes Unicode et que le traitement ultérieur utilise une forme de normalisation différente, des vulnérabilités exploitables apparaissent¹¹.

Considérons ce scénario : un logiciel de sécurité vérifie si un nom de fichier correspond au chemin sensible /etc/passwd.

L’attaquant crée un fichier dont le nom contient des caractères invisibles ou des variantes Unicode. Le logiciel de sécurité vérifie la chaîne, constate qu’elle n’est pas égale à /etc/passwd, et autorise l’accès.

Cependant, lors du traitement par le système de fichiers, ces variantes Unicode peuvent être normalisées en une forme équivalente à /etc/passwd, contournant ainsi le contrôle de sécurité.

Le CERT/CC a documenté des problèmes similaires dans le VU#999008 : les compilateurs autorisent les caractères de contrôle Unicode et les homoglyphes dans le code source, ce qui peut être utilisé pour masquer du code malveillant lors des revues de code¹².

TOCTOU : le problème de l’équivalence dans la dimension temporelle

Il existe une autre catégorie de vulnérabilités encore plus subtiles : les TOCTOU (Time-of-Check to Time-of-Use).

L’essence d’une faille TOCTOU est l’existence d’une fenêtre temporelle entre la vérification et l’utilisation, durant laquelle un attaquant peut modifier l’état du système pour invalider le résultat de la vérification¹³.

Dans le contexte des systèmes de fichiers, ce problème est étroitement lié à l’interprétation sémantique des noms de fichiers. Réfléchissons au processus d’accès à un fichier :

1. Le programme demande l’accès à un fichier en utilisant son nom.
2. Le noyau résout le nom de fichier en inode.
3. Le noyau vérifie les permissions.
4. Le noyau renvoie un descripteur de fichier.

Le problème est qu’entre l’étape 1 et l’étape 2, le mappage entre le nom de fichier et l’inode peut changer. Un attaquant peut, dans cette fenêtre, rediriger le nom de fichier vers un autre fichier.

L’insensibilité à la casse et la normalisation Unicode de macOS complexifient le problème TOCTOU. Lorsqu’un contrôle de sécurité utilise une forme de représentation du nom de fichier et que l’opération réelle sur le fichier utilise une autre représentation équivalente mais différente, la fenêtre TOCTOU s’élargit.

L’article « Unsafe at Any Copy: Name Collisions from Mixing Case Sensitivity » de l’USENIX FAST’23 a étudié ce problème de manière systématique¹⁵. L’étude a révélé des disparités dans les règles de pliage de casse et les techniques de normalisation entre différents systèmes de fichiers. Par exemple, temp_200K (où K est le signe Kelvin, U+212A) et temp_200k sont considérés comme identiques sur NTFS et APFS, mais différents sur ZFS.

Cette incohérence est un terreau fertile pour les failles de sécurité.

Défense en profondeur : quand le nom de fichier n’est pas fiable

Face à la réalité du manque de fiabilité des noms de fichiers, Apple a choisi une stratégie de défense en profondeur (Defense in Depth).

L’idée centrale de cette stratégie est la suivante : puisque nous ne pouvons pas rendre les noms de fichiers fiables, ne nous appuyons pas sur eux pour établir la confiance. Au lieu de cela, nous établissons des barrières de sécurité indépendantes à plusieurs niveaux, chacune utilisant une base de confiance différente.

Voyons comment Apple met en œuvre cette stratégie.

Arbres de Merkle et Volume Système Signé

macOS Big Sur (11.0) a introduit le mécanisme de Volume Système Signé (Signed System Volume, SSV)¹⁶. L’idée maîtresse du SSV est d’utiliser des hachages cryptographiques pour vérifier l’intégrité du système, plutôt que de se fier aux noms de fichiers.

L’implémentation technique du SSV repose sur les arbres de Merkle. Un arbre de Merkle est une structure de données élégante qui nous permet de vérifier l’intégrité d’un ensemble de données de n’importe quelle taille à l’aide d’un « hachage racine » de taille fixe¹⁷.

Le fonctionnement d’un arbre de Merkle est le suivant :

1. Diviser les données en plusieurs blocs et calculer le hachage de chaque bloc (nœuds feuilles).
2. Associer les hachages adjacents par paires et calculer leur hachage combiné (nœuds internes).
3. Répéter l’étape 2 jusqu’à ce qu’il ne reste qu’un seul hachage (nœud racine).

Cette structure possède une propriété clé : toute modification d’un bloc de données entraînera un changement de tous les hachages sur le chemin allant de ce nœud feuille à la racine. Par conséquent, tant que le hachage racine est fiable, nous pouvons vérifier l’intégrité de l’ensemble des données.

Dans l’implémentation du SSV, chaque fichier du volume système possède un hachage SHA-256 stocké dans les métadonnées du système de fichiers. Le hachage du nœud racine est appelé « sceau » (seal), et il couvre chaque octet du SSV.

Ce sceau est vérifié par le chargeur d’amorçage à chaque démarrage du Mac. Si la vérification échoue, le démarrage est interrompu et l’utilisateur est invité à réinstaller le système d’exploitation¹⁸.

Qu’est-ce que cela signifie ? Peu importe les confusions de casse, les variantes Unicode utilisées par un attaquant, ou même s’il obtient les privilèges Root : s’il tente de modifier quoi que ce soit sur le volume système, le hachage ne correspondra plus et le système refusera de démarrer. Les problèmes d’interprétation sémantique des noms de fichiers deviennent ici hors de propos — car l’intégrité de l’ensemble du volume est garantie par des hachages cryptographiques, et non par des noms de fichiers.

Marquage des métadonnées et SIP

Avant le SSV, macOS disposait déjà du SIP (System Integrity Protection), également connu sous le nom de rootless¹⁹. L’idée centrale du SIP est d’utiliser des marqueurs de métadonnées pour protéger les fichiers critiques, plutôt que de se fier aux noms de fichiers.

Le SIP a introduit un nouveau drapeau de fichier restricted. Un fichier marqué comme restricted ne peut pas être modifié, même par l’utilisateur root²⁰.

Le point crucial est que la vérification du SIP est basée sur les marqueurs de métadonnées de l’inode, et non sur le nom du fichier. Lorsqu’un processus tente d’écrire dans un répertoire protégé, le noyau vérifie si cet inode est marqué comme « protégé par le SIP ». Même si un attaquant trompe les contrôles de couches supérieures via des variantes Unicode ou des confusions de casse, lorsque la requête arrive au noyau, celui-ci examine le drapeau restricted de l’inode et rejette l’opération.

C’est un principe de conception important : déplacer la base de confiance du nom de fichier vers les métadonnées de l’inode. Le nom de fichier peut être obscurci, mais les métadonnées de l’inode sont gérées directement par le noyau et ne sont pas affectées par l’interprétation sémantique du nom.

Descripteurs de fichiers : contourner le nom de fichier

Dans sa documentation pour les développeurs, Apple préconise l’utilisation de NSURL (objet) et de File Descriptor (descripteur de fichier) plutôt que l’utilisation directe de chaînes de caractères de chemin de fichier²¹.

Ce choix de conception cache des considérations de sécurité profondes.

Sous le mécanisme de Sandbox (bac à sable), lorsque l’utilisateur autorise une application à accéder à un fichier, le système lui donne un Token plutôt qu’un chemin. L’application peut utiliser ce Token pour demander l’accès au fichier au noyau, lequel localise le fichier via l’inode.

Cette conception évite les problèmes complexes de résolution de chemin, de correspondance de casse et de normalisation Unicode. Plus important encore, elle élimine fondamentalement la possibilité de vulnérabilités TOCTOU — car le descripteur de fichier pointe directement vers l’inode, au lieu de s’y référer indirectement par un nom de fichier.

TCC : contrôle d’accès basé sur l’identité du processus

TCC (Transparency, Consent, and Control) est le framework utilisé par macOS pour gérer l’accès des applications aux données sensibles²². Le cœur de TCC est une base de données SQLite stockée dans /Library/Application Support/com.apple.TCC/TCC.db.

La caractéristique de sécurité clé de TCC est qu’il intercepte les accès en fonction de l’identité du processus (et non du nom de fichier). Lorsqu’un attaquant tente de lire un répertoire privé de l’utilisateur, TCC vérifie l’identité et les permissions du processus demandeur, plutôt que de simplement vérifier la chaîne de caractères du chemin du fichier.

La base de données TCC elle-même est protégée par le SIP et ne peut pas être modifiée directement²³. Pour interférer avec ces bases de données, un attaquant doit désactiver le SIP ou obtenir l’accès à un processus système de confiance.

Réflexion sur la philosophie de conception

En revenant aux critiques de Linus Torvalds, nous voyons qu’il ne s’agit pas seulement d’un problème technique, mais d’une question de philosophie de conception.

La philosophie de conception d’Unix met l’accent sur la simplicité et l’orthogonalité. Les noms de fichiers sont des séquences d’octets, et le noyau n’interprète pas leur signification. Les avantages de cette conception sont la prévisibilité et la sécurité — pas de conversions sémantiques cachées, pas de relations d’équivalence inattendues.

macOS a choisi une voie différente, cherchant à offrir une expérience plus conviviale à l’utilisateur. L’insensibilité à la casse permet à l’utilisateur de ne pas se soucier de la différence entre Document.txt et document.txt. La normalisation Unicode évite à l’utilisateur d’avoir à comprendre la différence entre NFD et NFC.

Mais cette convivialité a un prix. Lorsque le système de fichiers commence à « comprendre » les noms de fichiers, il assume la responsabilité de définir ce qui est « identique ». Or, la définition de l’identité est complexe, liée à la culture et en constante évolution.

Le problème plus profond est que lorsque nous utilisons des définitions de l’identité différentes à différents niveaux du système, des failles de sécurité apparaissent. Un programme de contrôle de sécurité peut utiliser une relation d’équivalence, le système de fichiers une autre, et l’attaquant exploite précisément cette incohérence pour contourner les contrôles.

La stratégie de défense en profondeur d’Apple est un compromis pragmatique. Puisqu’il est impossible de changer les décisions historiques (l’insensibilité à la casse est le comportement par défaut de macOS), des barrières de sécurité indépendantes sont établies aux niveaux supérieur et inférieur :

• Le SSV protège l’intégrité du système via des hachages cryptographiques.
• Le SIP protège les fichiers critiques via des marqueurs de métadonnées.
• Le descripteur de fichier contourne le nom de fichier pour utiliser directement l’inode.
• TCC protège les données utilisateur via l’authentification de l’identité du processus.

Le point commun de ces mécanismes est qu’ils ne font pas confiance au nom de fichier. Ils utilisent des hachages cryptographiques, des marqueurs de métadonnées, l’identité des processus et les inodes pour établir la confiance, plutôt que de s’appuyer sur des chaînes de caractères susceptibles d’être obscurcies.

Conclusion

La critique de Torvalds nous rappelle un principe fondamental : un système de sécurité ne devrait pas dépendre d’interprétations sémantiques complexes.

Un modèle simple, même s’il n’est pas parfait, est souvent plus fiable et prévisible qu’un modèle complexe. Le principe Unix « le nom de fichier est une séquence d’octets » est précisément un tel modèle simple : il renonce à la capacité de « comprendre » les noms de fichiers, mais gagne en prévisibilité et en sécurité.

L’histoire de macOS démontre le coût de la complexité. De la normalisation Unicode de HFS+ à l’insensibilité à la normalisation d’APFS, des failles Git aux attaques TOCTOU, l’interprétation sémantique des noms de fichiers a toujours été un nid à problèmes de sécurité.

Cependant, la stratégie de réponse d’Apple fait preuve d’une grande sagesse en ingénierie : lorsque nous ne pouvons pas éliminer la complexité, nous pouvons limiter son impact par une défense en profondeur. SSV, SIP, descripteurs de fichiers, TCC — aucun de ces mécanismes ne dépend de l’interprétation sémantique des noms de fichiers ; ils établissent des bases de confiance indépendantes à un niveau plus profond.

Pour les développeurs, les leçons de cette histoire sont claires :

• Ne supposez jamais qu’un nom de fichier est unique ou immuable.
• Utilisez des descripteurs de fichiers plutôt que des chaînes de chemin pour les opérations sur les fichiers.
• Lors des contrôles de sécurité, tenez compte de l’impact de la casse et de la normalisation Unicode.
• Lors du développement multiplateforme, testez vos applications dans des environnements sensibles et insensibles à la casse.

Comme le dit Torvalds, un nom de fichier ne devrait être qu’une suite d’octets. Dès que nous commençons à leur donner des significations magiques, nous ouvrons la boîte de Pandore.

Références