パス名ベースのMACのセキュリティトレードオフ（例：TOMOYO、grsecurity、AppArmorなど）
LinuxのMAC（Mandatory Access Control）システムについて学んでいます。多くの場合、ただし常にではありませんが、これらは Linux Security Modules に関連付けられています。私が見たいくつかのシステム： SELinux 、 Tomoyo 、 AppArmor 、 grsecurity 、 Smack 。
私が理解している限り、これらのシステムはすべて、ルールのカタログのセットアップに依存しています。これらのルールは、ファイルとシステムリソースに対するきめ細かいアクセスポリシーを定義し、セキュリティを強化します。
ファイルへのアクセスを制限する意図を考えると、「どの」ファイルを知る必要があるのは論理的であり、したがって、ファイル参照はこれらのルールが意味を持つために不可欠です。これは私の質問に関連しています。
SELinuxとSmackの顕著な例外を除いて、他のアプローチはfile paths（pathnames）を使用してルール内のファイルを識別します。 1つのファイルが同時に複数の名前（リンク、バインドマウントなど）を持つ可能性があるため、他の人がこのアプローチを安全でないと判断するのを見てきました。
パス名を使用するアプローチは安全ですか？これらのパス名ベースのスキームの利点と欠点は何ですか？ 「パス名ベースのMAC（TOMOYO、grsecurity、AppArmorなど）に実際の概念上の欠陥がある」と述べるのは正確でしょうか？
このアプローチは、1つのファイルが同時に複数の名前（リンク、バインドマウントなど）を持つ可能性があると述べて、安全でないと判断されることがよくあります。
1つのファイルに複数のセキュリティコンテキスト（名前ごとに1つ）を含めることができるのは確かです。ただし、これが安全かどうかは、それをどのように見るかによって異なります。
- AppArmorのこの機能は、リモートファイルシステムがAppArmorをサポートすることを必要としないので、たとえば、NFSパスに実装できます。
- 通常、Unix DACは有効なままなので、
/usr/binの内容などの興味深いアプリケーションでさえ書き込み可能であってはなりません。理論的には！ - エンドユーザーがマウントまたはシンボリックリンクするのを防ぐための追加のコントロールがある場合があります。
ただし、それを除けば、MACタイプのプロジェクトの目標は、ユーザーだけでなくプロセスも制限することです。そのため、ユーザーとして実行されるプロセスは、必要な権限でのみ実行されます。おそらくlnを除いて、ほとんどのアプリケーションは、シンボリックリンクを作成する機能と、すべてのディレクトリとパスでそれらを必要としないアプリケーションを必要とします。そのため、ほとんどのプロセスに必要な封じ込めを実装できるはずです。
パス名の潜在的な問題に悩まされているわけではありませんが、inodeベースのセキュリティには問題があります。
- ファイルセキュリティに添付された情報は、xattrs（拡張属性）に保存されます。これは、 ネットワークファイルシステム に関する特別な考慮事項を意味します。
- 一部のアプリケーションは inode値 を変更するため、セキュリティコンテキストの操作で問題が発生する可能性があります。具体的には、ファイルが に戻る可能性がありますデフォルトのセキュリティコンテキスト を編集し、
vimがこのように動作する場合。
その違いは非常に微妙であり、それぞれに長所と短所があるため、一方が他方よりも安全であるというわけではないと思います。適切に理解すると、どちらも安全なポリシーの実装を可能にします。
GrsecurityはTOMOYOやAppArmorのような純粋なパス名ベースのMACシステムではありません。ポリシーはパス名（SELinuxを含む他のすべてのシステムと同じ）を使用して記述されますが、これらは有効化時にinode/devペアに変換され、その後使用されます。パス名は、ポリシーからの正規表現に一致する場合、または「policy-recreation」を提供する場合にのみ使用されます。SELinuxの他のコメントで、vimによって変更されたファイルをデフォルトのセキュリティコンテキストに戻すケース（深刻な問題！）がある場合、grsecurityはこのケースを検出し、そのオブジェクトの以前のポリシーを新しいオブジェクトに適用します。
おかしなことに、純粋なパス名ベースのMACシステムでgrsecurityに集中してFUDを広める一方で、最近のバージョンではSELinux自体がファイル名情報の使用を追加して、grsecurityが1日目から行っていることを正確に実行しています。
ショーペンハウアーが言ったことは本当のようです：「すべての真実は3つの段階を通過します。最初にそれは嘲笑されます。2番目に、それは激しく反対されます。
このトピックの詳細については、grsecurity RBACチュートリアルプレゼンテーションで説明します。 https://grsecurity.net/rbac_tutorial.pdf
-ブラッド
パス名ベースのアクセス制御は一般的に概念的にまったく欠陥がなく、利点さえあるかもしれませんが、現在の実装は便利ではないと思います。
利点は、1か所でより明確で理解しやすいポリシーを指定できること、およびファイルシステム全体に広がるxattrsの複雑さがないことです。考えやすさ、これは重要です。 短所は、一部の実装では、ハードリンクや名前の変更をユーザー向けに簡単に /で処理できないことです。
TOMOYOの作者からの回答があります： http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#g6a56098 基本的に、重要なファイルのリンク/名前の変更を禁止することができ、それによってデフォルトのリンク/名前変更は禁止されているため、「問題ありません」。 ポリシーの作成と維持が（= /// =）複雑なのです。まあ、それはあなたがどのような目標を持っているかに依存します。