LSMとアクセス制御

Unixの権限が許可していても、ポリシーによってサービスが拒否される可能性がある。また、特定のcapabilityを持っているからといって、関連するすべての操作が許可されるわけではない。アクセス制御では、⁠主体、対象、操作、およびポリシーの組み合わせを一体的に解釈する必要がある。

DACにはowner/group/otherとACLが含まれ、通常はオブジェクトの所有者が権限を付与できる。強制ポリシーは、サービスドメインをさらに制約できる。

1. LSMはチェックの位置を提供し、モジュールがポリシーを提供する

LSMフックは、ファイル、資格情報、プロセス、ネットワークなどのカーネルオブジェクトの操作パス内に位置する。1つのシステムコールで複数のチェックがトリガーされる場合があり、カーネル内部の操作もこれらの位置を通ることがある。フックには、判断を返す関数のほか、安全状態の割り当て、解放、または更新を通知するものも含まれる。「すべてのフックがエラーを返せば拒否される」と一概には言えない。

例えば security_file_open() は、戻り値を持つ file_open フックを使用する。これを call_void_hook() として記述し、エラーチェックを主張するのは正しくない。ターゲットバージョンの security/security.c と include/linux/lsm_hook_defs.h を読む方が、古いバージョンのフックリスト構造をコピーするよりも信頼性が高い。

一般的な拒否型の権限フックでは、有効化されたモジュールが定義された組み合わせルールに従ってチェックに参加する。1つのモジュールによる拒否を、別のモジュールの許可で上書きすることはできない。SELinuxとAppArmorがすべてのシステムで固定された並列動作を行うと描くのは誤りである。実際の有効化の組み合わせと順序は、カーネルバージョン、構成、および起動パラメータに依存する。securityfsが見える場合、/sys/kernel/security/lsm に現在アクティブなモジュールがリストされる。

LSMという名前だからといって、それらが自由に insmod/rmmod できる通常のモジュールであるわけではない。フレームワークの概念についてはLSMドキュメントを参照のこと。ここで言及されている歴史的構造体は、現在のソースコードと合わせて読むべきである。

2. SELinux：主体ドメインとオブジェクトタイプ

SELinuxのセキュリティコンテキストには通常、user、role、type、およびレベル/範囲が含まれる。例えば、ファイルラベルの httpd_sys_content_t はオブジェクトタイプである。サービスプロセスは特定のドメインで実行される。

type enforcementの拒否レコードを読む際には、以下の4項目を一致させること。

パスだけを見ると、ラベル、ドメイン変換、またはディレクトリのsearch権限を見逃す可能性がある。ルールは、ソースドメインが対象タイプのある種のオブジェクトに対して行う操作の許可を表現している。

AVCはクエリコストを削減するためにアクセス判断をキャッシュする。ラベルのソースには、ファイルシステムの拡張属性や、ポリシーが特定のオブジェクトに対して生成したラベルが含まれる。procfs、tmpfsなどのマーキング方法がすべて genfscon によって生成されると一概には言えない。

Enforcingモードではポリシーが拒否を実行する。permissiveモードでは、本来拒否されるべきアクセスを記録するだけで、SELinuxによる拒否は適用されない。他のDAC、LSM、およびシステムエラーにより操作が失敗する可能性があるため、permissiveであってもすべての操作が成功するわけではない。監査はポリシーとログ設定の影響を受けるため、すべての判断に新しいログエントリが作成されるとは限らない。

3. AppArmorとSmack：異なるポリシー表現

AppArmorはプログラムプロファイルを中核とし、ファイルアクセスルールはパスに基づいて表現されることが多く、capabilityやネットワーク操作などを制限できる。同じUnixユーザー内の異なるプログラムは、異なる制約を受けることができる。

パスベースのポリシーを理解するには、プロセスのマウントビュー、エイリアス、リネーム、およびリンクルールを知る必要がある。しかし、「ハードリンクを作成したりbind mountを行ったりすればAppArmorを回避できる」と結論付けてはならない。リンクとマウント自体もチェックの対象であり、プロファイル、ポリシーネームスペース、および具体的なルールが結果を決定する。以下はルールの構文断片であり、デプロイ可能な完全なサービスプロファイルではない。

/var/www/** r,
/var/log/example/*.log w,
capability net_bind_service,

これには、プログラムの読み込み、ダイナミックライブラリ、ディレクトリアクセス、および完全な実行依存関係が含まれていない。理論的に1つのルールを理解することと、利用可能で十分に収束されたポリシーを持つことは、別の作業である。AppArmorドキュメントを参照。

Smackも主体/オブジェクトラベルとアクセスルールを使用するが、独自のルールと特殊なラベルセマンティクスを持つ。それは「SELinuxから特定の機能の固定パーセントを削除したバージョン」ではない。選択メカニズムは、実際の表現力とデプロイ環境を比較して決定すべきである。Smackドキュメントを参照。

4. Capabilities：権限を分割し、完全なサンドボックスは生成しない

カーネルのcapabilityセマンティクスはスレッド資格情報に基づき、permitted、effective、inheritable、およびboundingおよびambientセットを含む。通常の権限チェックでは、effectiveセット内の関連能力が関与する。exec時にどのように再計算されるかは、ファイルcapability、set-ID、securebitsなどの条件に依存する。

• CAP_NET_RAW は、raw/packetソケットなどの権限に関連する。
• CAP_SYS_PTRACE は、一部のptrace資格制限を回避するために使用できるが、他のチェックも存在する。
• CAP_NET_BIND_SERVICE は保護された低ポートに関連する。ネットワークネームスペースのポート閾値設定も、これを必要とするかどうかに影響する。
• CAP_SYS_ADMIN は範囲が非常に広いため、名前を狭い操作として理解すべきではない。

userネームスペース内のcapabilityは、適用されるネームスペースとオブジェクト関係内でのみ有効であり、コンテナ内のrootがホストrootのすべての能力を自動的に持つわけではない。逆に、capabilityを削除しても、通常ユーザーが本来使用できるすべてのインターフェースが削除されるわけではない。詳細はcapabilities(7)を参照。

DAC、capabilityの範囲、LSM、および読み取り専用ファイルシステム条件をそれぞれ分離して考える。以下に示すのは、これらの制約の組み合わせであり、すべてのシステムが固定された関数呼び出し順序に従うことを偽装するものではない。

5. BPF LSM：検証されたプログラムでもポリシーを誤って記述する可能性がある

BPF LSMは、権限で制御されたBPFプログラムを使用して、サポートされるフックを拡張することを許可する。libbpfは読み込みとリンクを処理でき、CO-RE/BTFはカーネルタイプの適応を支援する。

システム全体のMACフックの場合、複数のBPFプログラムがチェーンされる際、プログラムはインターフェースを通じて以前の拒否結果を保持する必要があり、渡された非ゼロの ret を無条件に0に変更してはならない。異なるattachタイプには異なる戻り値のセマンティクスがあり、1つの例の戻り値ルールをすべてのBPF LSMプログラムに直接適用することはできない。

verifierは、受け入れ可能なメモリアクセス、制御フローなどの条件をチェックし、プログラムがカーネルを破壊するリスクを低減する。しかし、ビジネスロジックの認可が正しいことを証明するものではなく、カーネル/verifierにバグがないことを約束するものでもない。誤ったポリシーをデプロイすると、通常の作業がブロックされる可能性がある。BPF LSMドキュメントを参照。

6. Keyring、IMA、およびEVM

カーネルのkeyringは、タイプ、権限、および寿命を持つkeyオブジェクトを管理し、keyをkeyringにリンクする機能をサポートする。これはすべてのユーザーがすべての秘密鍵を読み取れるグローバル辞書ではなく、各keyペイロードがハードウェアによって保護されることも保証されない。trusted、encryptedなどのkeyタイプには、それぞれ独自のラップとルートトラスト方式がある。

測定記録と使用時の拒否は異なる目標

IMAのmeasurementはポリシーに基づいてファイルなどのオブジェクトを測定し、測定ログを保持し、TPM PCRを拡張できる。それは1バイト読み込むたびにファイル全体を再計算するものではなく、各ファイルのハッシュをTPMに個別に保存するものでもない。リモート検証には、ログ、PCR、信頼できる証明、および期待される状態の両方を理解する必要がある。

IMAのappraisalは、ポリシーに基づいてファイルの整合性/真正性を検証し、使用を拒否するかどうかを決定する。EVMは選択されたセキュリティ拡張属性および関連メタデータの整合性を保護し、HMACまたは署名を使用できる。測定、実行拒否、およびディスクコンテンツの暗号化は3つの異なる目標である。測定ログだけでは、改ざんされたプログラムの実行を自動的に阻止できない。

7. 現在の環境を只読で観察する

from pathlib import Path

for name in ('/sys/kernel/security/lsm', '/sys/fs/selinux/enforce',
             '/proc/self/attr/current'):
    try:
        print(name, Path(name).read_text().strip())
    except OSError as exc:
        print(name, type(exc).__name__)
for line in Path('/proc/self/status').read_text().splitlines():
    if line.startswith(('Cap', 'NoNewPrivs:', 'Seccomp:')):
        print(line)

ファイルが見えない場合は、securityfsのマウント漏れ、構成、権限、またはコンテナビューに起因する可能性がある。読み取り失敗だけで、システムにアクセス制御が何もないと断言してはならない。実際の認可問題は、サービスプロセスの資格情報、ネームスペース、ラベル/プロファイル、および拒否ログと組み合わせて検討すべきであり、現在のシェルをチェックするだけでは不十分である。

参考：カーネルキー管理、整合性メカニズムのソース。