Linuxサーバを運用していると、従来のファイル・アクセス権（ユーザー／グループ／その他）だけでは心もとない場面があります。たとえば、
- Webサーバが万が一侵害され、攻撃者がroot権限を奪取すると全てが危険
- プロセス間の不正なアクセスを細かく制御したい
そんなときに有効なのが「SELinux（Security-Enhanced Linux）」です。米NSA（アメリカ国家安全保障局）の研究成果をもとにRed Hatが実装したセキュリティ機構で、強力なMandatory Access Control（強制アクセス制御）を実現します。
本記事では、SELinuxの基本概念から制御モデル、実践的な設定・トラブルシューティングまで、基礎からじっくり解説します。
1. 用語の整理
SELinuxを理解する前提として、まずセキュリティ用語をおさらいしましょう。
1.1 DAC（Discretionary Access Control：任意アクセス制御）
従来のUnix/Linuxで使われる「誰がどのファイルを読めるか」を示す制御モデル。
- ファイル所有者が自由にパーミッションを変更可能
- 柔軟だが、所有者の設定ミスや悪意あるプロセスの操作をも許してしまうリスクがある
1.2 MAC（Mandatory Access Control：強制アクセス制御）
システム管理者が定義したポリシーに基づき、ユーザーやプロセスに必ず制約を課すモデル。
- 所有者でもポリシーで禁止された操作は実行不可
- システム全体で統一的なセキュリティレベルを維持
1.3 RBAC（Role-Based Access Control：役割ベース制御）
ユーザーに「役割(Role)」を割り当て、その役割ごとにアクセス権を管理する方法。
- 大規模組織でのアクセス管理に有効
- SELinuxでもRBAC要素を一部取り入れている
2. SELinuxのアーキテクチャ概観
SELinuxはLinux KernelのLSM (Linux Security Modules)フレームワークを通じて動作します。主なコンポーネントは以下。
- ポリシー
- 許可・拒否ルールの集合。Type Enforcement（TE）やMLS（多レベルセキュリティ）などのモデルで記述
- セキュリティサーバ（ユーザランド）
load_policyやsemanageなどでポリシーを操作
- カーネルフック
- システムコール実行時にLSMフックが呼び出され、許可チェックを実施
- ラベル（コンテキスト）
- ファイルやプロセスに付与される文字列。例：
system_u:object_r:httpd_sys_content_t:s0
- ファイルやプロセスに付与される文字列。例：
3. ポリシーの基礎：Type Enforcement（TE）
SELinuxの中心はType Enforcementです。各オブジェクト（ファイル、ソケットなど）にはtypeが割り当てられ、プロセスにもtypeが設定されます。ポリシーでは「あるタイプのプロセスが、別のタイプのオブジェクトに対して何の操作をしていいか」を細かく定義します。
allow httpd_t httpd_sys_content_t:file { read open };
allow httpd_t httpd_sys_script_exec_t:file { read open execute };httpd_t：プロセスタイプ（Apache httpd）httpd_sys_content_t：静的コンテンツ用ファイルタイプ{ read open }：許可する操作
このように、ディレクトリ階層やUnixパーミッションに依存せず、きめ細かく制御できます。
4. 制御モデルの種類
SELinuxポリシーには大きく分けて以下のモデルがあります。
| モデル | 特徴 | 用途 |
|---|---|---|
| Targeted | 一部のプロセスのみSELinuxで制御（デフォルト） | WebサーバやDBなど主要サービス |
| MLS (Multi-Level Security) | 情報の機密性レベル（Top Secret, Secret…）でアクセス制御 | 国家機関など |
| MCS (Multi-Category Security) | MLSを簡易化し、カテゴリー（例：プロジェクトA, B）で制御 | コンテナ環境の分離など |
初めて導入するなら、Targeted Policyで動作確認し、必要に応じて拡張しましょう。
5. ラベルとコンテキストの仕組み
SELinuxでは、ファイルやプロセスに対して「ラベル（コンテキスト）」を付与します。主な構成要素は以下の通り。
user:role:type:level- user：SELinuxユーザー（system_u, user_uなど）
- role：CLCに似た概念（object_r, staff_rなど）
- type：最重要！アクセス制御対象
- level：MLS/MCSで使用
たとえば、Apacheのコンテンツファイルには通常次のようなラベルが付与されます。
system_u:object_r:httpd_sys_content_t:s0ラベルの確認・変更には以下コマンドを使用します。
# 現在のラベルを確認
ls -Z /var/www/html/index.html
# ラベルを手動で付け替え
chcon -t httpd_sys_content_t /path/to/file
# 永続的に設定
semanage fcontext -a -t httpd_sys_content_t "/myapp(/.*)?"
restorecon -R /myapp
6. SELinuxの有効化・設定・確認
6.1 ステータス確認
# モードとポリシー名を表示
sestatus
# 例:
# SELinux status: enabled
# Current mode: enforcing
# Mode from config file: enforcing
# Policy name: targeted6.2 モード変更
| モード | 説明 |
|---|---|
| Enforcing | ポリシーどおりにアクセス制御を実行 |
| Permissive | 許可しない操作もログに記録するのみ |
| Disabled | SELinux機能を停止（再起動要） |
# 一時的にPermissiveへ変更
setenforce 0
# 元に戻す
setenforce 16.3 ログの読み方とトラブル対応
アクセス拒否が発生すると、/var/log/audit/audit.logや/var/log/messagesに以下のようなログが出力されます。
type=AVC msg=audit(162....): avc: denied { read } for pid=1234 comm="httpd" name="secret.txt" dev="sda1" ino=56789 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file- scontext：アクセスしたプロセスのラベル
- tcontext：対象ファイルのラベル
ログをもとに、必要な許可ルールをaudit2allowで生成できます。
# 拒否ログからポリシー追加用モジュールを生成
grep httpd /var/log/audit/audit.log | audit2allow -M myhttpd
# 生成されたmyhttpd.ppを読み込む
semodule -i myhttpd.ppこれで再度動作確認してみましょう。
7. SELinux導入のメリット・デメリット
メリット
- 堅牢なセキュリティ：プロセス横断的な侵害防止
- 細粒度制御：Unixパーミッションを超えた制御
- ログ活用：不正操作の兆候を即座に検知
デメリット
- 学習コスト：ポリシーやラベルの理解が必要
- 運用負荷：許可エラー対応やポリシー調整
- アプリ互換性：一部アプリで動作しない場合あり
8. まとめ：まずはPermissiveで様子見するのもあり
SELinuxは初めてだと敷居が高く感じられるかもしれません。しかし、
- Targeted Policyを使って
- Permissiveモードでログを確認し
- 問題となるアクセスを
audit2allowで対応
というステップで導入すれば、運用しながらセキュリティを強化できます。
サーバ運用者として、万が一の侵害に備えた多層防御の一翼を担うSELinux、ぜひ一度触ってみてください！
