# ファイル名のセマンティック・トラップ：同値関係から見るmacOSのセキュリティ設計

はじめに

「同じ」とは何でしょうか？

この一見単純な問いは、コンピュータシステムにおいては罠に満ちています。2025年4月、Linus TorvaldsはLinuxカーネルのメーリングリストにおいて、bcachefsのケースフォールディング（case-folding）機能に対し、激しい口調のメールを投稿しました¹。彼の核心的な論点は、次の一言に集約されます。「ファイル名は単なるバイト列であるべきであり、ファイルシステムがそれらを『理解』しようとすべきではない」

これは単なる技術的な好みの問題ではありません。ファイル名に「Aとaは同じである」や「éとe+´は同じである」といった意味論（セマンティクス）を付与し始めた瞬間、私たちはパンドラの箱を開けることになります。

この問題の本質をさらに深く理解していきましょう。

ファイル名の本質：識別子か、それとも名前か？

図書館では、各書籍を識別する方法が2つあります。「書名」と「請求記号」です。書名には意味があり、その本が何について書かれているかを伝えます。一方、請求記号は不透明な一意の識別子であり、書架での場所を特定するためだけに存在します。

Unixの設計者は「請求記号」モデルを選択しました。

Unixの設計哲学において、ファイル名は不透明なバイト列です。カーネルの職務は単純で、このバイト列をinode（インデックスノード）にマッピングすることだけです。O’Reilly出版の『Understanding the Linux Kernel』に記されているように、「Unixファイルはバイトシーケンスとして構造化された情報コンテナであり、カーネルはファイルの内容を解釈しない」²のです。この「解釈しない」という哲学は、ファイル名にも同様に適用されます。

この設計選択の背後にある深い理由は何でしょうか？

「単純さ」は「予測可能性」をもたらします。ファイル名が単なるバイト列であれば、システムの挙動は完全に確定的になります。2つのファイル名が同じであるのは、それらのバイト列が完全に一致する場合のみです。曖昧さも、特殊なケースも、文化への依存もありません。VFS（Virtual File System）層はdentryキャッシュを通じてパス名をinodeに解決しますが、このプロセスは純粋なバイトマッチングです³。

しかし、macOSは異なる道を選びました。

同値関係：同じであることが複雑になるとき

数学において、同値関係とは「自反律（a ~ a）」「対称律（a ~ b ならば b ~ a）」「推移律（a ~ b かつ b ~ c ならば a ~ c）」の3つの性質を満たす関係を指します。大文字小文字を区別しない（ケースインセンシティブ）と言うとき、私たちは実質的に「A ~ a」「B ~ b」といった同値関係を定義していることになります。

これは単純なことのように思えませんか？

しかし問題は、「誰がその同値関係を定義するのか」にあります。システムによって定義が異なる可能性があるのです。

英語では「i」の大文字は「I」であり、これは自明に思えます。しかし、トルコ語には4つの異なる「i」が存在します。

トルコ語では、「i」の大文字は「İ」（点付きの大文字I）であり、「I」の小文字は「ı」（点なしの小文字i）です⁴。つまり、あるセキュリティチェックが英語のルールに従って「FILE」を小文字化して「file」を得る一方で、ファイルシステムがトルコ語のルールに従って「fıle」を得た場合、これら2つの文字列は一致しません。たとえそれらが「同じ」ファイル名であるべきだとしてもです。

これは深刻な問題を浮き彫りにしています。大文字小文字の変換は、普遍的で文化に依存しない操作ではないのです。ファイルシステム層でケースインセンシティブを実装する場合、特定のルールを選択しなければならず、その選択がユーザー空間のプログラムが使用するルールと矛盾する可能性があります。

Unicode正規化：さらに深いウサギの穴

大文字小文字の区別だけでも十分に複雑ですが、Unicode正規化（Normalization）は問題をさらなる次元へと押し上げます。

まず、単純な問いから始めましょう。「é」は1つの文字でしょうか、それとも2つの文字でしょうか？

Unicodeにおける答えは「どちらでもあり得る」です。「é」は単一のコードポイント U+00E9 (LATIN SMALL LETTER E WITH ACUTE) で表すこともできれば、2つのコードポイント U+0065 (LATIN SMALL LETTER E) + U+0301 (COMBINING ACUTE ACCENT) の組み合わせで表すこともできます。これら2つの表現は視覚的には全く同じですが、バイトレベルでは全く異なります。

1
合成済み形式（NFC）：C3 A9           -> é
2
分解形式（NFD）：    65 CC 81        -> e + ́ → é

Unicode標準は、NFC、NFD、NFKC、NFKDという4つの正規化形式を定義しています⁶。NFCは合成済み文字を使用する傾向があり、NFDは文字を基底文字と結合記号に分解する傾向があります。

HFS+はNFDを選択しました。Appleの技術文書によると、HFS+は「Unicode Normalization Form Dに非常に近い」正規化形式を使用しています⁷。つまり、「café」という名前のファイルを作成すると、システムは自動的に「é」を「e + ´」の2つのコードポイントに分解します。

この設計判断には合理性があります。強制的に正規化を行うことで、HFS+は同じ「文字」に対して1つの表現方法しかないことを保証し、ユーザーが「見た目は同じだが実際には異なる」2つのファイルを作成してしまうことを防いでいます。

しかし、ここで重大な問題があります。HFS+の正規化ルールはUnicode 3.2に基づいており、このルールはUnicode標準の進化に合わせて更新することができません。なぜなら、「そのような進化は既存のHFS+ボリュームを無効にしてしまうから」です⁸。

2017年、AppleはHFS+の後継としてAPFSを導入しました。APFSは重要な変更を行いました。Unicode正規化を強制するのをやめ、「正規化を維持するが正規化を区別しない（normalization-preserving but normalization-insensitive）」方式を採用したのです⁹。これは、APFSが入力された元のバイト列を保持しつつ、ファイル名の比較時には正規化の等価性を考慮することを意味します。

この変更によりいくつかの問題は解決されましたが、新たな問題も生じました。HFS+からAPFSへ移行する際、元々正規化されていたファイル名はNFD形式を維持しますが、新しく作成されるファイルはNFC形式を使用する可能性があります。特定の境界条件において、これにより「見た目は同じだが実際には異なる」ファイル名が同一ディレクトリ内に共存してしまう可能性があります。

セキュリティ脆弱性の本質：同値関係の不一致

ここで、セキュリティ脆弱性の本質を理解することができます。

セキュリティチェックプログラムとファイルシステムが異なる同値関係を使用しているとき、「隙間」が生じます。攻撃者は、セキュリティチェックプログラムからは安全に見えるが、ファイルシステムからは危険なファイル名と同等とみなされるファイル名を構築できるのです。

Torvaldsはメールの中でこの問題を的確に描写しています。

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… （セキュリティ上の問題、例えば「ユーザー空間でファイル名がセキュリティに敏感なパターンに一致しないことを確認した」とする。しかし、その後、脳みそが足りないファイルシステムが結局そのパターンに一致させてしまうのだ……）

具体的な例を見てみましょう。

2021年3月、Gitプロジェクトは深刻な脆弱性 CVE-2021-21300 を公開しました¹⁰。この脆弱性は、ケースインセンシティブなファイルシステムを使用しているWindowsおよびmacOSユーザーに特に影響を与えました。

この脆弱性の原理は、Gitの lstat キャッシュメカニズムに関係しています。Gitがファイルをチェックアウトする際、システムコールを減らすためにキャッシュを維持します。攻撃者は、「A」と「a」という2つのファイルを含む悪意のあるリポジトリを構築できます。ケースセンシティブなファイルシステムではこれらは異なる2つのファイルですが、ケースインセンシティブなファイルシステムでは衝突が発生します。

攻撃の鍵は、Gitの内部ロジック（ケースセンシティブを前提としている）とファイルシステムの挙動（ケースインセンシティブ）の間の不一致にあります。攻撃者はこの不一致を利用して、Gitのチェックアウトプロセス中に任意のコードを実行させることができました。

Unicode正規化がもたらすセキュリティ問題はさらに巧妙です。Black Hat USA 2019の研究論文「Host/Split: Exploitable Antipatterns in Unicode Normalization」によれば、セキュリティの決定がUnicode文字列に基づいて行われ、その後の処理で異なる正規化形式が使用される場合、悪用可能な脆弱性が生じます¹¹。

次のようなシナリオを考えてみましょう。セキュリティソフトウェアが、ファイル名が /etc/passwd という機密パスに一致するかどうかをチェックします。

攻撃者は、名前に不可視文字やUnicodeの異体字を含むファイルを作成します。セキュリティソフトウェアが文字列をチェックすると、/etc/passwd とは一致しないと判断し、アクセスを許可します。

しかし、ファイルシステムが低レイヤーで処理を行う際、これらのUnicode異体字を /etc/passwd と等価な形式に正規化してしまい、結果としてセキュリティチェックを回避できてしまうのです。

CERT/CCは VU#999008 において同様の問題を記録しています。コンパイラがソースコード内にUnicode制御文字やホモグラフ（同形異義語）を許可している場合、コードレビュー時に悪意のあるコードを隠蔽するために悪用される可能性があります¹²。

TOCTOU：時間軸における同値関係の問題

さらに巧妙な種類の脆弱性として、TOCTOU（Time-of-Check to Time-of-Use）があります。

TOCTOU脆弱性の本質は、チェック（Check）と使用（Use）の間に時間的な窓（ウィンドウ）が存在し、攻撃者がその窓の中でシステムの状態を変更してチェック結果を無効にできることにあります¹³。

ファイルシステムの文脈では、この問題はファイル名の意味解釈と密接に関連しています。ファイルアクセスのプロセスを考えてみましょう。

1. プログラムがファイル名を使用してファイルへのアクセスを要求する
2. カーネルがファイル名をinodeに解決する
3. カーネルが権限をチェックする
4. カーネルがファイル記述子（ファイルディスクリプタ）を返す

問題は、ステップ1とステップ2の間で、ファイル名からinodeへのマッピングが変化する可能性があることです。攻撃者はこの窓の間で、ファイル名を別のファイルを指すように書き換えることができます。

macOSのケースインセンシティブとUnicode正規化は、TOCTOU問題をさらに複雑にします。セキュリティチェックがあるファイル名表現を使用し、実際のファイル操作が別の等価だが異なる表現を使用する場合、TOCTOUの窓は拡大します。

USENIX FAST’23の論文「Unsafe at Any Copy: Name Collisions from Mixing Case Sensitivity」はこの問題を体系的に研究しています¹⁵。研究の結果、異なるファイルシステム間でのケースフォールディングルールや正規化技術には差異があることが判明しました。例えば、temp_200K（Kはケルビン記号 U+212A）と temp_200k は、NTFSとAPFSでは同じとみなされますが、ZFSでは異なるとみなされます。

このような不一致は、セキュリティ脆弱性の温床となります。

多層防御：ファイル名が信頼できないとき

ファイル名が信頼できないという現実に直面し、Appleは多層防御（Defense in Depth）戦略を選択しました。

この戦略の核心的な考え方は、「ファイル名を信頼できるようにすることは不可能なので、信頼を築くためにファイル名に依存しない」というものです。代わりに、複数のレイヤーで独立したセキュリティ障壁を構築し、各障壁が異なる信頼の基盤を使用するようにします。

Appleがどのようにこの戦略を実現しているかを見てみましょう。

Merkleツリーと署名済みシステムボリューム

macOS Big Sur (11.0) では、署名済みシステムボリューム（Signed System Volume, SSV）メカニズムが導入されました¹⁶。SSVの核心的な考え方は、ファイル名に依存するのではなく、暗号化ハッシュを使用してシステムの整合性を検証することです。

SSVの技術的な実装はMerkleツリーに基づいています。Merkleツリーは、固定サイズの「ルートハッシュ」を使用して、任意のサイズのデータセットの整合性を検証できるエレガントなデータ構造です¹⁷。

Merkleツリーの仕組みは以下の通りです。

1. データをいくつかのブロックに分割し、各ブロックのハッシュ値を計算する（リーフノード）
2. 隣接するハッシュ値をペアにし、それらを組み合わせたハッシュを計算する（内部ノード）
3. ハッシュ値が1つになるまでステップ2を繰り返す（ルートノード）

この構造には重要な特性があります。どのデータブロックが変更されても、そのリーフノードからルートノードに至るパス上のすべてのハッシュ値が変化します。したがって、ルートハッシュが信頼できるものであれば、データセット全体の整合性を検証できます。

SSVの実装では、システムボリューム上の各ファイルのSHA-256ハッシュ値がファイルシステムのメタデータに保存されています。ルートノードのハッシュ値は「シール（seal）」と呼ばれ、SSV上のすべてのバイトをカバーしています。

このシールは、Macの起動のたびにブートローダーによって検証されます。検証に失敗すると起動が中断され、ユーザーにOSの再インストールが促されます¹⁸。

これが何を意味するかというと、攻撃者がどのような大文字小文字の難読化やUnicode異体字を使用しようとも、あるいはRoot権限を取得したとしても、システムボリュームの内容を少しでも変更しようとすればハッシュ値が一致しなくなり、システムは起動を拒否します。ファイル名の意味解釈の問題は、ここでは無関係になります。ボリューム全体の整合性はファイル名ではなく、暗号化ハッシュによって保証されているからです。

メタデータタグとSIP

SSV以前から、macOSにはSIP（System Integrity Protection）、別名「rootless」が存在していました¹⁹。SIPの核心的な考え方は、ファイル名に依存するのではなく、メタデータタグを使用して重要なファイルを保護することです。

SIPは新たに restricted というファイルフラグを導入しました。restricted とマークされたファイルは、たとえrootユーザーであっても変更できません²⁰。

重要なのは、SIPのチェックがファイル名ではなく、inodeのメタデータタグに基づいている点です。プロセスが保護されたディレクトリに書き込もうとすると、カーネルはそのinodeが「SIP保護対象」としてマークされているかどうかを確認します。攻撃者がUnicode異体字や大文字小文字の難読化で上位レイヤーのチェックを欺いたとしても、要求がカーネルに届いた時点で、カーネルはinodeの restricted フラグを見て操作を拒否します。

これは重要な設計原則です。信頼の基盤をファイル名からinodeのメタデータへと移すのです。ファイル名は難読化できますが、inodeのメタデータはカーネルによって直接管理されており、ファイル名の意味解釈の影響を受けません。

ファイル記述子：ファイル名をバイパスする

Appleは開発者ドキュメントにおいて、ファイルパス文字列を直接使用するのではなく、NSURL（オブジェクト）やファイル記述子（File Descriptor）を使用することを推奨しています²¹。

この設計選択の背後には、深いセキュリティ上の考慮があります。

サンドボックス（Sandbox）メカニズムの下で、ユーザーがアプリにあるファイルへのアクセスを許可すると、システムはアプリにパスではなくトークン（Token）を与えます。アプリはこのトークンを使用してカーネルにファイルアクセスを要求し、カーネルはinodeを通じてファイルを特定します。

この設計により、複雑なパス解決、大文字小文字のマッチング、Unicode正規化の問題が回避されます。さらに重要なことに、ファイル記述子はファイル名を通じて間接的に参照するのではなく、直接inodeを指すため、根本的にTOCTOU脆弱性の可能性を排除できます。

TCC：プロセスアイデンティティに基づくアクセス制御

TCC（Transparency, Consent, and Control）は、macOSがアプリケーションによる機密データへのアクセスを管理するためのフレームワークです²²。TCCの核心は、/Library/Application Support/com.apple.TCC/TCC.db に保存されているSQLiteデータベースです。

TCCの重要なセキュリティ特性は、ファイル名ではなくプロセスアイデンティティ（身元）に基づいてアクセスを遮断する点にあります。攻撃者がユーザーのプライバシーディレクトリを読み取ろうとすると、TCCは単にファイルパス文字列をチェックするのではなく、要求を行っているプロセスのアイデンティティと権限をチェックします。

TCCデータベース自体もSIPによって保護されており、直接変更することはできません²³。これらのデータベースに干渉するには、攻撃者はSIPを無効にするか、信頼されたシステムプロセスへのアクセス権を取得する必要があります。

設計哲学の再考

Linus Torvaldsの批判に立ち返ると、これが単なる技術的な問題ではなく、設計哲学の問題であることがわかります。

Unixの設計哲学は、単純さと直交性を強調します。ファイル名はバイト列であり、カーネルはその意味を解釈しません。この設計の利点は、予測可能性とセキュリティにあります。隠れた意味変換も、予期せぬ同値関係も存在しません。

macOSは異なる道を選び、ユーザーによりフレンドリーな体験を提供しようとしました。ケースインセンシティブにより、ユーザーは Document.txt と document.txt の違いを心配する必要がなくなりました。Unicode正規化により、ユーザーはNFDとNFCの差異を理解する必要がなくなりました。

しかし、このフレンドリーさには代償があります。ファイルシステムがファイル名を理解し始めたとき、それは「同じ」とは何かを定義する責任を負うことになります。そして「同じ」の定義は複雑で、文化に依存し、絶えず進化し続けるものです。

さらに深い問題は、システムの異なるレイヤーで異なる「同じ」の定義を使用しているときに、セキュリティ脆弱性が生じることです。セキュリティチェックプログラムがある同値関係を使用し、ファイルシステムが別の同値関係を使用している場合、攻撃者はその不一致を利用してセキュリティチェックを回避します。

Appleの多層防御戦略は、現実的な妥協案です。歴史的な決定（ケースインセンシティブはすでにmacOSのデフォルトの挙動であること）を変えることはできないため、より高いレイヤーとより低いレイヤーで独立したセキュリティ障壁を構築したのです。

• SSVは暗号化ハッシュを通じてシステムの整合性を保護する
• SIPはメタデータタグを通じて重要なファイルを保護する
• ファイル記述子はファイル名をバイパスし、直接inodeを使用する
• TCCはプロセス認証を通じてユーザーデータを保護する

これらのメカニズムに共通する特徴は、「ファイル名を信頼していない」ことです。これらは暗号化ハッシュ、メタデータタグ、プロセスアイデンティティ、そしてinodeを使用して信頼を構築しており、難読化される可能性のある文字列には依存していません。

結語

Torvaldsの批判は、私たちに基本原則を思い出させてくれます。それは「セキュリティシステムは複雑な意味解釈に依存すべきではない」ということです。

単純なモデルは、たとえ完璧ではなくても、複雑なモデルよりも信頼性が高く、予測可能であることが多いのです。Unixの「ファイル名はバイト列である」という考え方は、まさにそのような単純なモデルです。ファイル名を「理解」する能力を放棄する代わりに、予測可能性とセキュリティを手に入れました。

macOSの歴史は、複雑さの代償を証明しています。HFS+のUnicode正規化からAPFSの正規化不感性、Gitの脆弱性からTOCTOU攻撃に至るまで、ファイル名の意味解釈は常にセキュリティ問題の温床となってきました。

しかし、Appleの対応戦略もまた、エンジニアリングの知恵を示しています。複雑さを排除できないとき、多層防御を通じてその影響を制限することができます。SSV、SIP、ファイル記述子、TCC。これらのメカニズムはいずれもファイル名の意味解釈に依存せず、より低レイヤーで独立した信頼の基盤を築いています。

開発者にとって、この物語の教訓は明確です。

• ファイル名が一意である、あるいは不変であると決して仮定しないこと
• ファイル操作にはパス文字列ではなくファイル記述子を使用すること
• セキュリティチェックを行う際は、大文字小文字やUnicode正規化の影響を考慮すること
• クロスプラットフォーム開発の際は、ケースセンシティブとインセンシティブの両方の環境でテストすること

Torvaldsが言うように、ファイル名は単なるバイト列であるべきです。私たちがそれらに魔法のような意味を付与し始めたとき、私たちはパンドラの箱を開けてしまうのです。

参考文献