# Semantische Fallen bei Dateinamen: Das Sicherheitsdesign von macOS aus der Perspektive von Äquivalenzrelationen

Einleitung

Was bedeutet „gleich“?

Diese scheinbar einfache Frage ist in Computersystemen voller Tücken. Im April 2025 veröffentlichte Linus Torvalds auf der Linux-Kernel-Mailingliste eine scharf formulierte E-Mail zur Case-Folding-Funktion von bcachefs¹. Sein Kernargument lässt sich in einem Satz zusammenfassen: Dateinamen sollten lediglich eine Folge von Bytes sein; das Dateisystem sollte nicht versuchen, sie zu „verstehen“.

Dies ist nicht nur eine Frage technischer Vorlieben. Wenn wir beginnen, Dateinamen eine Semantik zu verleihen – etwa indem das System versteht, dass A und a identisch sind oder dass é und e+´ dasselbe bedeuten –, öffnen wir die Büchse der Pandora.

Lassen Sie uns das Wesen dieses Problems genauer betrachten.

Das Wesen von Dateinamen: Identifikator oder Name?

In einer Bibliothek gibt es für jedes Buch zwei Arten der Kennzeichnung: den Buchtitel und die Signatur (Standortnummer). Der Buchtitel hat eine Semantik; er sagt Ihnen, worum es in dem Buch geht. Die Signatur hingegen ist opak; sie ist lediglich ein eindeutiger Identifikator, um das Buch im Regal zu lokalisieren.

Die Unix-Entwickler entschieden sich für das Modell der „Signatur“.

In der Unix-Designphilosophie ist ein Dateiname eine opake Byte-Sequenz. Die Aufgabe des Kernels ist einfach: Diese Byte-Sequenz auf einen Inode (Index-Knoten) abzubilden. Wie in „Understanding the Linux Kernel“ von O’Reilly beschrieben: „A Unix file is an information container structured as a sequence of bytes; the kernel does not interpret the contents of a file.“² Diese Philosophie der „Nicht-Interpretation“ gilt gleichermaßen für Dateinamen.

Was ist der tiefere Grund für diese Designentscheidung?

Einfachheit bringt Vorhersehbarkeit. Wenn Dateinamen lediglich Byte-Sequenzen sind, ist das Verhalten des Systems absolut determiniert: Zwei Dateinamen sind genau dann gleich, wenn ihre Byte-Sequenzen identisch sind. Es gibt keine Mehrdeutigkeiten, keine Sonderfälle und keine kulturellen Abhängigkeiten. Die VFS-Schicht (Virtual File System) löst Pfadnamen über den Dentry-Cache in Inodes auf, aber dieser Prozess ist ein reiner Byte-Vergleich³.

macOS hat jedoch einen anderen Weg gewählt.

Äquivalenzrelationen: Wenn Gleichheit kompliziert wird

In der Mathematik ist eine Äquivalenzrelation eine Beziehung, die drei Eigenschaften erfüllt: Reflexivität (a ~ a), Symmetrie (wenn a ~ b, dann b ~ a) und Transitivität (wenn a ~ b und b ~ c, dann a ~ c). Wenn wir von Case-Insensitivity (Groß-/Kleinschreibung ignorieren) sprechen, definieren wir eigentlich eine Äquivalenzrelation: A ~ a, B ~ b und so weiter.

Das klingt einfach, oder?

Das Problem ist jedoch: Wer definiert diese Äquivalenzrelation? Verschiedene Systeme können unterschiedliche Definitionen haben.

Im Englischen ist die Großschreibung von i ein I – das scheint offensichtlich. Aber das Türkische kennt vier verschiedene i:

Im Türkischen ist der Großbuchstabe von i ein İ (großes I mit Punkt), während der Kleinbuchstabe von I ein ı (kleines i ohne Punkt) ist⁴. Das bedeutet: Wenn eine Sicherheitsprüfung nach englischen Regeln FILE in Kleinbuchstaben umwandelt und file erhält, das Dateisystem aber nach türkischen Regeln fıle verwendet, stimmen diese beiden Zeichenfolgen nicht überein – obwohl sie eigentlich derselbe Dateiname sein „sollten“.

Dies offenbart ein tiefgreifendes Problem: Die Umwandlung von Groß- und Kleinschreibung ist keine universelle, kulturübergreifende Operation. Wenn wir Case-Insensitivity auf Dateisystemebene implementieren, müssen wir uns für eine spezifische Regel entscheiden – und diese Wahl stimmt möglicherweise nicht mit den Regeln der User-Space-Programme überein.

Unicode-Normalisierung: Ein noch tieferer Kaninchenbau

Wenn Case-Insensitivity schon kompliziert genug ist, hebt die Unicode-Normalisierung das Problem in eine neue Dimension.

Beginnen wir mit einer einfachen Frage: Ist é ein Zeichen oder sind es zwei?

In Unicode lautet die Antwort: „Beides ist möglich“. é kann durch einen einzelnen Codepoint U+00E9 (LATIN SMALL LETTER E WITH ACUTE) dargestellt werden oder durch zwei Codepoints: U+0065 (LATIN SMALL LETTER E) + U+0301 (COMBINING ACUTE ACCENT). Diese beiden Darstellungen sind visuell identisch, auf Byte-Ebene jedoch völlig verschieden:

1
Precomposed Form (NFC): C3 A9           -> é
2
Decomposed Form (NFD):  65 CC 81        -> e + ́ → é

Der Unicode-Standard definiert vier Normalisierungsformen: NFC, NFD, NFKC und NFKD⁶. NFC bevorzugt vorkomponierte Zeichen, während NFD Zeichen in Basiszeichen plus Kombinationszeichen zerlegt.

HFS+ entschied sich für NFD. Laut technischer Dokumentation von Apple verwendet HFS+ eine Normalisierungsform, die „Unicode Normalization Form D sehr nahe kommt“⁷. Das bedeutet, wenn Sie eine Datei namens café erstellen, zerlegt das System das é automatisch in die zwei Codepoints e + ´.

Diese Designentscheidung hat ihre Berechtigung: Durch die erzwungene Normalisierung stellt HFS+ sicher, dass es für dasselbe „Zeichen“ nur eine Darstellungsweise gibt, wodurch verhindert wird, dass Benutzer zwei Dateien erstellen, die „gleich aussehen, aber tatsächlich verschieden sind“.

Aber hier liegt ein entscheidendes Problem: Die Normalisierungsregeln von HFS+ basieren auf Unicode 3.2. Diese Regeln können nicht mit der Entwicklung des Unicode-Standards aktualisiert werden, da „eine solche Entwicklung bestehende HFS+-Volumes ungültig machen würde“⁸.

2017 führte Apple APFS als Ersatz für HFS+ ein. APFS nahm eine wichtige Änderung vor: Es erzwingt keine Unicode-Normalisierung mehr, sondern ist normalization-preserving but normalization-insensitive⁹. Das bedeutet, APFS bewahrt die ursprüngliche Byte-Sequenz Ihrer Eingabe, berücksichtigt aber beim Vergleich von Dateinamen weiterhin die Normalisierungsäquivalenz.

Diese Änderung löste einige Probleme, schuf aber neue. Bei der Migration von HFS+ zu APFS behalten ursprünglich normalisierte Dateinamen ihre NFD-Form, während neu erstellte Dateien die NFC-Form verwenden können. In bestimmten Grenzfällen kann dies dazu führen, dass „gleich aussehende, aber tatsächlich verschiedene“ Dateinamen im selben Verzeichnis koexistieren.

Das Wesen von Sicherheitslücken: Inkonsistente Äquivalenzrelationen

Jetzt können wir das Wesen dieser Sicherheitslücken verstehen.

Wenn ein Sicherheitsprüfungsprogramm und das Dateisystem unterschiedliche Äquivalenzrelationen verwenden, entsteht eine „Lücke“. Ein Angreifer kann einen Dateinamen konstruieren, der für das Sicherheitsprüfungsprogramm harmlos erscheint, für das Dateisystem jedoch äquivalent zu einem gefährlichen Dateinamen ist.

Torvalds beschrieb dieses Problem in seiner E-Mail präzise:

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…

Betrachten wir ein konkretes Beispiel.

Im März 2021 deckte das Git-Projekt eine schwerwiegende Sicherheitslücke auf (CVE-2021-21300)¹⁰. Diese Lücke betraf insbesondere Windows- und macOS-Benutzer, die ein Case-Insensitive-Dateisystem verwenden.

Das Prinzip der Lücke betrifft den lstat-Caching-Mechanismus von Git. Wenn Git Dateien auscheckt, unterhält es einen Cache, um Systemaufrufe zu reduzieren. Ein Angreifer kann ein bösartiges Repository konstruieren, das zwei Dateien enthält: A und a. Auf einem Case-Sensitive-Dateisystem sind dies zwei verschiedene Dateien; auf einem Case-Insensitive-Dateisystem kommt es jedoch zu einem Konflikt.

Der Kern des Angriffs liegt in der Inkonsistenz zwischen der internen Logik von Git (basierend auf der Annahme von Case-Sensitivity) und dem Verhalten des Dateisystems (Case-Insensitivity). Ein Angreifer nutzt diese Inkonsistenz aus, um Git dazu zu bringen, während des Checkout-Prozesses beliebigen Code auszuführen.

Sicherheitsprobleme durch Unicode-Normalisierung sind noch subtiler. Laut dem Forschungsbericht „Host/Split: Exploitable Antipatterns in Unicode Normalization“ der Black Hat USA 2019 entstehen ausnutzbare Lücken, wenn Sicherheitsentscheidungen auf Unicode-Strings basieren, die anschließende Verarbeitung jedoch eine andere Normalisierungsform verwendet¹¹.

Stellen Sie sich folgendes Szenario vor: Eine Sicherheitssoftware prüft, ob ein Dateiname mit dem sensiblen Pfad /etc/passwd übereinstimmt.

Ein Angreifer erstellt eine Datei, deren Name unsichtbare Zeichen oder Unicode-Varianten enthält. Die Sicherheitssoftware prüft den String, stellt fest, dass er nicht /etc/passwd entspricht, und lässt ihn passieren.

Das Dateisystem könnte diese Unicode-Varianten jedoch bei der Verarbeitung im Hintergrund in eine Form normalisieren, die äquivalent zu /etc/passwd ist, und so die Sicherheitsprüfung umgehen.

CERT/CC dokumentierte in VU#999008 ähnliche Probleme: Compiler erlauben Unicode-Steuerzeichen und Homoglyphen im Quellcode, was dazu genutzt werden kann, bösartigen Code bei Code-Reviews zu verbergen¹².

TOCTOU: Äquivalenzprobleme in der Zeitdimension

Es gibt eine weitere Klasse noch subtilerer Lücken: TOCTOU (Time-of-Check to Time-of-Use).

Das Wesen einer TOCTOU-Lücke ist: Zwischen der Prüfung und der Verwendung existiert ein Zeitfenster, in dem ein Angreifer den Systemzustand ändern kann, sodass das Prüfergebnis ungültig wird¹³.

Im Kontext von Dateisystemen ist dieses Problem eng mit der semantischen Interpretation von Dateinamen verknüpft. Betrachten wir den Prozess des Dateizugriffs:

1. Ein Programm fordert den Zugriff auf eine Datei unter Verwendung eines Dateinamens an.
2. Der Kernel löst den Dateinamen in einen Inode auf.
3. Der Kernel prüft die Berechtigungen.
4. Der Kernel gibt einen File Descriptor zurück.

Das Problem ist: Zwischen Schritt 1 und Schritt 2 kann sich die Abbildung vom Dateinamen zum Inode ändern. Ein Angreifer kann in diesem Fenster den Dateinamen auf eine andere Datei umleiten.

Die Case-Insensitivity und Unicode-Normalisierung von macOS machen das TOCTOU-Problem noch komplexer. Wenn die Sicherheitsprüfung eine bestimmte Darstellung des Dateinamens verwendet, die tatsächliche Dateioperation jedoch eine andere, äquivalente Darstellung nutzt, vergrößert sich das TOCTOU-Fenster.

Das Paper „Unsafe at Any Copy: Name Collisions from Mixing Case Sensitivity“ der USENIX FAST’23 untersuchte dieses Problem systematisch¹⁵. Die Studie ergab, dass Unterschiede in den Case-Folding-Regeln und Normalisierungstechniken verschiedener Dateisysteme existieren. Zum Beispiel werden temp_200K (wobei K das Kelvin-Zeichen U+212A ist) und temp_200k auf NTFS und APFS als identisch betrachtet, auf ZFS jedoch als verschieden.

Diese Inkonsistenz ist ein Nährboden für Sicherheitslücken.

Defense in Depth: Wenn Dateinamen nicht vertrauenswürdig sind

Angesichts der Tatsache, dass Dateinamen nicht vertrauenswürdig sind, hat Apple eine Strategie der abgestuften Verteidigung (Defense in Depth) gewählt.

Der Kerngedanke dieser Strategie ist: Da wir Dateinamen nicht vertrauenswürdig machen können, sollten wir uns nicht auf sie verlassen, um Vertrauen aufzubauen. Stattdessen errichten wir unabhängige Sicherheitsbarrieren auf mehreren Ebenen, wobei jede Barriere eine andere Vertrauensbasis nutzt.

Sehen wir uns an, wie Apple diese Strategie umsetzt.

Merkle-Bäume und das Signed System Volume

macOS Big Sur (11.0) führte den Mechanismus des Signed System Volume (SSV) ein¹⁶. Die Kernidee von SSV ist: Die Systemintegrität wird mittels kryptografischer Hashes verifiziert, anstatt sich auf Dateinamen zu verlassen.

Die technische Implementierung von SSV basiert auf Merkle-Bäumen. Ein Merkle-Baum ist eine elegante Datenstruktur, die es uns ermöglicht, die Integrität eines Datensatzes beliebiger Größe mit einem „Root-Hash“ fester Größe zu verifizieren¹⁷.

Ein Merkle-Baum funktioniert wie folgt:

1. Die Daten werden in Blöcke unterteilt und der Hashwert jedes Blocks berechnet (Blattknoten).
2. Benachbarte Hashwerte werden gepaart und ihr kombinierter Hash berechnet (interne Knoten).
3. Schritt 2 wird wiederholt, bis nur noch ein Hashwert übrig bleibt (Wurzelknoten).

Diese Struktur hat eine entscheidende Eigenschaft: Jede Änderung an einem Datenblock führt dazu, dass sich alle Hashwerte auf dem gesamten Pfad von diesem Blattknoten bis zum Wurzelknoten ändern. Solange der Root-Hash vertrauenswürdig ist, können wir also die Integrität des gesamten Datensatzes verifizieren.

In der SSV-Implementierung verfügt jede Datei auf dem System-Volume über einen SHA-256-Hashwert, der in den Metadaten des Dateisystems gespeichert ist. Der Hashwert des Wurzelknotens wird als Seal (Siegel) bezeichnet und deckt jedes einzelne Byte auf dem SSV ab.

Dieses Seal wird bei jedem Start des Macs vom Bootloader verifiziert. Schlägt die Verifizierung fehl, wird der Startvorgang abgebrochen und der Benutzer aufgefordert, das Betriebssystem neu zu installieren¹⁸.

Was bedeutet das? Unabhängig davon, welche Case-Folding-Tricks oder Unicode-Varianten ein Angreifer verwendet – selbst wenn er Root-Rechte erlangt – stimmt der Hashwert nicht mehr überein, sobald er versucht, den Inhalt des System-Volumes zu ändern, und das System verweigert den Start. Die semantische Interpretation von Dateinamen wird hier irrelevant, da die Integrität des gesamten Volumes durch kryptografische Hashes und nicht durch Dateinamen garantiert wird.

Metadaten-Flags und SIP

Vor SSV gab es in macOS bereits SIP (System Integrity Protection), auch bekannt als „rootless“¹⁹. Die Kernidee von SIP ist: Kritische Dateien werden durch Metadaten-Flags geschützt, anstatt sich auf Dateinamen zu verlassen.

SIP führte ein neues restricted-Dateiflag ein. Dateien, die als restricted markiert sind, können nicht geändert werden, selbst wenn man als Root-Benutzer agiert²⁰.

Der entscheidende Punkt ist: Die SIP-Prüfung basiert auf dem Metadaten-Flag des Inodes, nicht auf dem Dateinamen. Wenn ein beliebiger Prozess versucht, in ein geschütztes Verzeichnis zu schreiben, prüft der Kernel, ob dieser Inode als „SIP-geschützt“ markiert ist. Selbst wenn ein Angreifer die oberen Prüfungsschichten durch Unicode-Varianten oder Case-Folding täuscht, sieht der Kernel beim Eintreffen der Anfrage das restricted-Flag des Inodes und verweigert die Operation.

Dies ist ein wichtiges Designprinzip: Die Vertrauensbasis wird vom Dateinamen auf die Metadaten des Inodes verlagert. Dateinamen können verschleiert werden, aber die Metadaten eines Inodes werden direkt vom Kernel verwaltet und sind nicht von der semantischen Interpretation des Dateinamens betroffen.

File Descriptoren: Den Dateinamen umgehen

Apple empfiehlt in seiner Entwicklerdokumentation die Verwendung von NSURL (Objekten) und File Descriptoren statt direkter Dateipfad-Strings²¹.

Hinter dieser Designentscheidung stehen tiefgreifende Sicherheitsüberlegungen.

Unter dem Sandbox-Mechanismus erhält eine App, wenn der Benutzer ihr den Zugriff auf eine Datei erlaubt, ein Token statt eines Pfades. Die App kann über dieses Token beim Kernel den Dateizugriff anfordern, und der Kernel lokalisiert die Datei über den Inode.

Dieses Design umgeht komplexe Pfadauflösungen, Case-Matching und Unicode-Normalisierungsprobleme. Noch wichtiger ist, dass es TOCTOU-Lücken fundamental eliminiert, da der File Descriptor direkt auf den Inode zeigt und nicht indirekt über einen Dateinamen referenziert.

TCC: Zugriffskontrolle basierend auf Prozessidentität

TCC (Transparency, Consent, and Control) ist das Framework von macOS zur Verwaltung des Zugriffs von Anwendungen auf sensible Daten²². Das Herzstück von TCC ist eine SQLite-Datenbank, die unter /Library/Application Support/com.apple.TCC/TCC.db gespeichert ist.

Das entscheidende Sicherheitsmerkmal von TCC ist: Es fängt Zugriffe basierend auf der Prozessidentität (statt des Dateinamens) ab. Wenn ein Angreifer versucht, ein privates Verzeichnis des Benutzers zu lesen, prüft TCC die Identität und Berechtigungen des anfordernden Prozesses, anstatt lediglich den Dateipfad-String zu prüfen.

Die TCC-Datenbank selbst ist durch SIP geschützt und kann nicht direkt geändert werden²³. Um diese Datenbanken zu manipulieren, müsste ein Angreifer SIP deaktivieren oder Zugriff auf einen vertrauenswürdigen Systemprozess erlangen.

Reflexion über die Designphilosophie

Zurück zu Linus Torvalds’ Kritik: Wir sehen, dass dies nicht nur ein technisches Problem ist, sondern eine Frage der Designphilosophie.

Die Unix-Designphilosophie betont Einfachheit und Orthogonalität. Dateinamen sind Byte-Sequenzen; der Kernel interpretiert ihre Bedeutung nicht. Die Vorteile dieses Designs sind Vorhersehbarkeit und Sicherheit – es gibt keine versteckten semantischen Transformationen und keine unerwarteten Äquivalenzrelationen.

macOS hat einen anderen Weg gewählt und versucht, dem Benutzer eine freundlichere Erfahrung zu bieten. Case-Insensitivity sorgt dafür, dass sich Benutzer keine Gedanken über den Unterschied zwischen Document.txt und document.txt machen müssen. Die Unicode-Normalisierung erspart es dem Benutzer, den Unterschied zwischen NFD und NFC verstehen zu müssen.

Aber diese Freundlichkeit hat ihren Preis. Wenn ein Dateisystem beginnt, Dateinamen zu „verstehen“, übernimmt es die Verantwortung dafür, zu definieren, was „gleich“ ist. Und die Definition von Gleichheit ist komplex, kulturabhängig und entwickelt sich ständig weiter.

Das tieferliegende Problem ist: Wenn wir auf verschiedenen Ebenen des Systems unterschiedliche Definitionen von Gleichheit verwenden, entstehen Sicherheitslücken. Ein Sicherheitsprüfungsprogramm verwendet vielleicht eine Äquivalenzrelation, das Dateisystem eine andere, und Angreifer nutzen genau diese Inkonsistenz aus, um Sicherheitsprüfungen zu umgehen.

Apples Defense-in-Depth-Strategie ist ein pragmatischer Kompromiss. Da historische Entscheidungen nicht rückgängig gemacht werden können (Case-Insensitivity ist das Standardverhalten von macOS), werden auf höheren und niedrigeren Ebenen unabhängige Sicherheitsbarrieren errichtet:

• SSV schützt die Systemintegrität durch kryptografische Hashes.
• SIP schützt kritische Dateien durch Metadaten-Flags.
• File Descriptoren umgehen Dateinamen und nutzen direkt Inodes.
• TCC schützt Benutzerdaten durch Prozessidentitätsprüfung.

Das gemeinsame Merkmal dieser Mechanismen ist: Sie vertrauen Dateinamen nicht. Sie nutzen kryptografische Hashes, Metadaten-Flags, Prozessidentitäten und Inodes, um Vertrauen aufzubauen, anstatt sich auf potenziell verschleierbare Strings zu verlassen.

Fazit

Torvalds’ Kritik erinnert uns an ein grundlegendes Prinzip: Sicherheitssysteme sollten nicht von komplexen semantischen Interpretationen abhängen.

Ein einfaches Modell ist, auch wenn es unvollkommen ist, oft zuverlässiger und vorhersehbarer als ein komplexes Modell. Das Unix-Prinzip „Dateinamen sind Byte-Sequenzen“ ist genau ein solches einfaches Modell: Es verzichtet auf die Fähigkeit, Dateinamen zu „verstehen“, gewinnt dafür aber Vorhersehbarkeit und Sicherheit.

Die Geschichte von macOS beweist den Preis der Komplexität. Von der Unicode-Normalisierung in HFS+ bis zur Normalisierungsunempfindlichkeit in APFS, von Git-Lücken bis zu TOCTOU-Angriffen – die semantische Interpretation von Dateinamen war stets ein Nährboden für Sicherheitsprobleme.

Aber Apples Gegenstrategie zeigt auch technisches Geschick: Wenn wir Komplexität nicht eliminieren können, können wir ihre Auswirkungen durch abgestufte Verteidigung begrenzen. SSV, SIP, File Descriptoren, TCC – all diese Mechanismen hängen nicht von der semantischen Interpretation von Dateinamen ab; sie schaffen eine unabhängige Vertrauensbasis auf einer tieferen Ebene.

Für Entwickler ist die Lehre aus dieser Geschichte klar:

• Gehen Sie niemals davon aus, dass Dateinamen eindeutig oder unveränderlich sind.
• Verwenden Sie File Descriptoren statt Pfad-Strings für Dateioperationen.
• Berücksichtigen Sie bei Sicherheitsprüfungen die Auswirkungen von Case-Insensitivity und Unicode-Normalisierung.
• Testen Sie bei plattformübergreifender Entwicklung sowohl in Case-Sensitive- als auch in Case-Insensitive-Umgebungen.

Wie Torvalds sagte: Dateinamen sollten lediglich eine Folge von Bytes sein. Wenn wir beginnen, ihnen magische Bedeutungen zu verleihen, öffnen wir die Büchse der Pandora.

Referenzen