Linux Security Modules（LSM）：カーネルセキュリティフックのフレームワーク

中核概念とアーキテクチャ

LSMは、カーネル内の戦略的な箇所に小さなコールバックフックを挿入することで動作します。たとえば、ファイルを開くとき、プロセスを作成またはシグナル送信するとき、ソケットを使用するとき、ネットワークパケットを処理するときなどです。フックされたイベントが発生すると、カーネルは登録済みモジュールの関数を呼び出し、その操作を許可すべきかどうかを判断します。フレームワーク自体はポリシーを定義しません。モジュールがポリシーロジックを実装し、ラベルや規則といった関連状態を保持します。このフレームワークは、より広範なLinuxカーネルのコードベースの一部であり、カーネルのコーディング規約およびインターフェース規約に従います。

代表的な実装

• SELinux — オブジェクトと主体にラベルを割り当て、複雑なポリシーを強制する、広く利用されている強制アクセス制御システムです。
• AppArmor — パスベースのアクセス制御と管理の容易さに重点を置く、プロファイルベースの隔離機構です。
• Smack — 組込みシステム向けに設計された、より単純なラベルベースのMACです。
• TOMOYO — 観測されたプログラムの動作からポリシーを学習できる、動作重視の隔離機構です。
• Landlock — 非特権プロセスが軽量なサンドボックスを作成できるようにすることを目的としたLSMです。

これらの実装は、強制アクセス制御、サンドボックス化、ポリシーの複雑さに対する異なるアプローチを示しています。きめ細かな制御や形式的なポリシー言語を優先するものもあれば、単純さと管理負担の軽減を目指すものもあります。

歴史と発展

LSM機構は、単一のセキュリティモデルを中核部分に固定的に組み込むことを避けるため、汎用フック層としてメインラインカーネルに導入されました。統合以降、開発者やディストリビューションは、多様なセキュリティ上の要件を満たすために各種モジュールを採用してきました。時とともにこのモデルは発展してきました。当初は一度に一つの主要モジュールを有効化することが中心でしたが、その後の取り組みにより互換性が向上し、コンテナやデスクトップの隔離といった現代の用途に対応するため、特定のモジュールのスタッキングまたは共存が可能になりました。

用途と重要性

LSMは、強制アクセス制御、アプリケーションのサンドボックス化、権限の縮小、コンテナ化されたワークロードの隔離を実装するために広く使用されています。システム管理者は、攻撃対象領域の削減、最小権限の強制、規制またはコンプライアンス要件への対応のためにLSMモジュールを利用します。このフレームワークはGNU GPLの下でライセンスされているため、LSMとそのモジュールはカーネルソースの他の部分とともに配布・開発されます。カーネルのライセンスに関する注記は、カーネルライセンスを参照してください。

主な相違点

LSMは、POSIX ACLや従来の任意アクセス制御などのアクセス制御機構とは異なります。カーネルフックのレベルで動作し、ユーザーの判断を上書きし得る、システム全体に適用される多くの場合強制的なポリシーをサポートするためです。LSMは単一の製品ではなく、柔軟な基盤です。どのモジュールを導入するかは、表現力、性能、管理の複雑さの望ましい均衡によって決まります。

管理者と開発者にとって、LSMフックがどこで発生するか、またモジュールがセキュリティ属性をどのように保持・検査するかを理解することは、効果的なポリシーを設計する鍵となります。文書化やモジュール固有のツールは異なるため、本番環境での導入では、必要なセキュリティ態勢を実現するために、LSMの選定をポリシー管理、監査、テストの方針と組み合わせることが一般的です。