SELinux（Security-Enhanced Linux、エスイーリナックス）は、米国家安全保障局（NSA）が中心となって開発したLinuxカーネルのセキュリティモジュールで、強制アクセス制御（MAC：Mandatory Access Control）をLinuxにもたらした代表的な実装です。従来のUNIX系オーナーシップ・パーミッションに基づく任意アクセス制御（DAC）に加え、プロセスとファイルそれぞれに付与されるセキュリティコンテキスト（label）に基づき、ポリシーで定められた操作だけを許可します。RHEL／CentOS／Fedoraなどでは標準有効化されており、サーバー堅牢化の代表的な手段として広く使われています。
この記事の目次
- SELinuxを支える3つの中核概念
- SELinuxの状態確認と運用の基本フロー
- SELinux活用のための重要なチェック項目
- SELinuxと従来DACの違い
- まとめ
SELinuxを支える3つの中核概念
SELinuxの中核を担うのが、セキュリティコンテキスト（label）です。全てのプロセスとファイル、ソケット、ポートに user:role:type:level というラベルが付与され、ls -Z や ps -Z で確認できます。例えばhttpdプロセスは httpd_t、Webコンテンツファイルは httpd_sys_content_t といった type が割り当てられ、これらの type 間で許可された操作のみが実行できる仕組みになっています。
操作を許可する関係を記述したものがSELinuxポリシーで、典型的にはtargetedポリシーが使われ、重要なサービス（httpd、sshd、postgresql等）にだけ強い制限を課す方式を採ります。ポリシーは多数のモジュールに分かれ、semanage や semodule で管理できます。モードはEnforcing（違反を遮断）、Permissive（違反を許容しログのみ）、Disabled（完全無効）の3種があり、構築時はPermissiveで挙動を観察し、運用に入る際にEnforcingへ切り替える流れが定石です。
SELinuxの状態確認と運用の基本フロー
SELinux運用の基本は状態確認から始まります。getenforce で現在のモードを表示し、sestatus で詳細な状態（policy種類、ローダ状態、現在のモード等）を確認します。トラブルシューティングでは、まず /var/log/audit/audit.log に出力されるAVCメッセージ（denied）を確認するのが基本で、ausearch -m AVC -ts recent や sealert ツールがメッセージの解釈を補助します。
違反が確認されたら、本当に許可すべき操作かを慎重に判断します。正当な必要があれば audit2allow -a -M mymodule のように既存のauditログから許可ルールを自動生成し、semodule -i mymodule.pp でポリシーモジュールとして適用できます。設定可能項目には、Boolean（getsebool／setsebool で切替可能なon/offスイッチ）、ファイルコンテキスト（semanage fcontext で永続的に定義）、ポート（semanage port）などがあり、これらの組み合わせで非常に細やかな制御が可能です。chconは一時的、restoreconは恒久的（fcontext反映）と覚えておくと迷いません。
SELinux活用のための重要なチェック項目
SELinuxを活用する上でまず重要なのは、組織としての方針を明確にすることです。Enforcingを基本とするか、Permissiveで監査のみ行うか、どうしても運用上の理由があってDisabledにするかは、セキュリティ要件と運用負荷のバランスから判断します。多くの組織ではRHEL系のデフォルトであるtargetedポリシー＋Enforcingを採用するのが標準ですが、いきなり本番でEnforcingにすると業務影響が大きいため、検証段階ではPermissiveに切り替えてauditログを取り、違反パターンを潰してから本番化するアプローチが安全です。
誤りやすい運用ミスとして、chcon でコンテキストを変更しても、restorecon やパッケージ更新で元に戻されてしまう点があります。恒久的な変更には semanage fcontext -a -t httpd_sys_content_t '/srv/web(/.*)?' のようにポリシーへ登録し、restorecon -Rv /srv/web で反映する手順を取ります。サービス挙動を変えたいときは Boolean が便利で、setsebool -P httpd_can_network_connect on のように -P 付きで永続化します。SSHのポート変更などは semanage port で行わないとSELinuxにブロックされるため、設定変更時は「ポリシー側にも申告する」癖をつけることが堅牢な運用の鍵です。
SELinuxと従来DACの違い
従来UNIXの権限モデル（DAC）は、ファイルの所有者と所属グループ、それに対するread／write／executeの組み合わせで動作判定を行います。シンプルで分かりやすい一方、rootは全ての権限を持ち、ユーザーが自分のファイルの権限を自由に変更できるため、脆弱性で乗っ取られたサービスがrootに昇格すると、システム全体が無防備に晒されるという根本的な弱さを抱えています。
SELinuxの強制アクセス制御は、ユーザーやrootの権限とは独立に、ポリシーで定められた組み合わせ以外の操作を一律拒否します。httpdが脆弱性で乗っ取られても、httpd_tドメインに与えられた操作（特定ファイル群への限定アクセス、特定ポートへの接続等）以外は許可されず、攻撃の横展開を大幅に遅らせます。設計と運用のコストは増えますが、防御の深さは確実に向上します。AppArmorはより使いやすい代替MAC実装として知られていますが、RHEL系のように最初からSELinuxが組み込まれた環境では、無効化せず正しく付き合うことが、現代の堅牢なLinux運用の前提条件となっています。
まとめ
SELinuxは、従来のDACに加えて強制アクセス制御をLinuxにもたらした代表的なセキュリティモジュールであり、RHEL系を中心に標準的に有効化されています。コンテキスト・ポリシー・モードという3つの中核概念を押さえ、auditログ・audit2allow・semanage・Booleanといった道具立てに慣れれば、適切に共存させながらサービスを堅牢化できます。「面倒だから無効化」ではなく、正しく付き合う姿勢が、現代のLinuxサーバーを守る上で欠かせない選択になります。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント