目次
0. SELinuxの基本概念と仕組み
SELinux（Security-Enhanced Linux）は、従来のLinuxの権限管理（DAC: 任意アクセス制御）を強化し、「プロセスごとにアクセスできる対象を厳しく制限する（MAC: 強制アクセス制御）」仕組みです。
従来（伝統的Linux）とSELinuxの違い
| 方式 | 内容 |
|---|---|
| 従来の管理（DAC） | root（管理者）権限を持つプロセスであれば、システム内のほぼすべてのファイルにアクセス可能。 |
| SELinux（MAC） | たとえroot権限であっても、「あらかじめ許可されたルール（ポリシー）」にないファイルやポートへのアクセスは遮断されます。これにより、万が一Webサーバーなどが乗っ取られても、システム全体に被害が拡大するのを防ぎます。 |
システム構成図（SELinuxのアーキテクチャ）
SELinuxがシステム内でどのように割り込んでアクセスをチェックしているかを示す図です。
動作シーケンス図（遮断時の流れ）
不正なアクセスが発生した際、SELinuxがどのように機能し、管理者に通知されるかの一連の流れです。
第1章：現在のステータス確認
設定作業を始める前に、現在のSELinuxの状態を正しく把握することが重要です。
① SELinuxの状態を確認する
以下のコマンドを実行して、現在の動作モードを確認します。
sestatus出力結果の確認ポイント
SELinux status: enabled になっているか確認します。Current mode（現在のモード）には以下の3つの状態があります。
| 動作モード | 状態 | 説明 |
|---|---|---|
| Enforcing | 強制モード | ポリシーに違反するアクセスを「遮断」し、ログに記録します（推奨状態）。 |
| Permissive | 許容（警告）モード | アクセスは「遮断せず許可」しますが、違反ログのみ記録します（トラブル特定用）。 |
| Disabled | 無効 | SELinuxの機能自体が完全にオフになっています。 |
第2章：ログの確認方法と「管理者」の心得
SELinuxが動作している場合、一般ユーザーがアクセス権限のないリソースにアクセスしようとすると「Permission denied（許可がありません）」と表示されます。これはセキュリティが正常に機能している証拠です。
① 一般ユーザーでの確認（テスト）
一般ユーザー（例：adminuserユーザーなど）でログインし、システム内の機密ファイルを開こうとしてみます。
cat /etc/shadow想定される結果：cat: /etc/shadow: 許可がありません (Permission denied)
意味：システムの重要なファイルが、管理者以外の一般ユーザーから見えないように保護されています。
② 管理者としてログを確認する（要sudo）
SELinuxの拒否ログやシステムログは、一般ユーザーから盗み見られないよう厳重に保護されています。内容を確認するには、必ず sudo（管理者権限）を用います。
1. システム全体ログの直近50行を確認する
sudo tail -n 50 /var/log/messages2. SELinux専用の監査ログ（拒否記録）を確認する
sudo tail -n 50 /var/log/audit/audit.log※このログには「何が（ソース）」「何に対して（ターゲット）」「どのような操作（アクセス）」を行おうとして拒否されたか（AVC情報）が記録されます。
第3章：トラブルシューティング・ツールの導入と活用
生の監査ログ（audit.log）は専門的で解読が難しいため、これを人間が理解しやすい「日本語（または英語）の説明」に自動変換するツールを導入します。
① ツールのインストール
sudo dnf install -y setroubleshoot-serverこのツールを導入すると、SELinuxがアクセスをブロックした際、/var/log/messages 内に以下のようなガイダンスが出力されるようになります。
SELinux is preventing ... To solve this, run: sealert -l [ID]② 魔法のコマンド sealert による解決策の出力
システムに不具合（例：メールが送れない、Webページが表示されない等）が発生した際、以下のコマンドを実行することで、SELinuxが原因であるかとその解決策を提示してくれます。
ログ全体から原因と対策を自動分析・出力する
sudo sealert -a /var/log/audit/audit.log | less提示されるメッセージの構成
このコマンドを実行すると、以下のような構成で解決策が明示されます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【問題の要約】
SELinux は、○○（プロセス名）が △△（ファイルやディレクトリ）に
アクセスするのを阻止しました。
【詳細情報】
Source (何が) : /usr/libexec/postfix/local
Access (何をしようとしたか) : create / write
Target (どこに) : /root/Maildir
【解決策の提示 (Solution)】
If you want to allow ... then you must ...
（もしこれを許可したい場合は、次のコマンドを実行してください：○○○）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━第4章：SELinuxを「強制（Enforcing）モード」に移行・固定する
システムを安全に保つため、動作モードを「Permissive（警告のみ）」から「Enforcing（強制遮断）」に切り替えます。
設定テストを行うため、現在のセッションでのみモードを切り替えます。
sudo setenforce 1# sudo setenforce 0切り替え後、sestatus を実行して Current mode: enforcing になっていることを確認します。
サーバーが再起動しても常に強制モードで起動するように、設定ファイルを編集します。
sudo vi /etc/selinux/configファイル内の以下の行を探し、enforcing に書き換えます。
# 変更前
SELINUX=permissive
# 変更後
SELINUX=enforcing保存して閉じます（:wq）。
※設定を完全に反映し、システム全体のファイルラベルの不整合を防ぐため、可能なタイミングでサーバーを再起動（sudo reboot）することをお勧めします。
第5章：実例で学ぶ「正しい解決アプローチ」
SELinuxでエラーが出た際、提示されたコマンドを盲目的に実行して「ポリシー自体を緩めてしまう」のは避けるべきケースがあります。アプリケーション側の設定（設計）を見直すことが、より安全な解決に繋がります。
実例：Postfix（メールサーバー）からエラーが出るケース
SELinuxをEnforcingにしたところ、以下のようなエラーログが記録されました。
| 項目 | 内容 |
|---|---|
| ソース（実行者） | postfix/local |
| ターゲット（対象） | /root/Maildir（rootユーザーのメールボックス） |
| 拒否内容 | 書き込み拒否 |
1. 間違った解決アプローチ（セキュリティを弱める方法）
sealertが提示した「ポリシー変更コマンド（audit2allow）」をそのまま実行し、Postfixプロセスが管理者（root）のホームディレクトリを自由に読み書きできるようにしてしまう。
リスク：メールサーバーの脆弱性を突かれた際、システム全体（root権限領域）を掌握される危険性が高まります。
2. 正しい解決アプローチ（システム設計の最適化）
「そもそも、システムからの通知メール（root宛て）を、rootディレクトリに直接書き込ませる設計自体が非推奨である」と考えます。
対策：root宛てのメールを、一般ユーザー（例：your_username）の受信箱に転送する設定（エイリアス設定）に変更します。これにより、Postfixは安全な一般ユーザーの領域にのみ書き込むようになり、SELinuxエラーも自然に解消されます。
具体的な変更手順
sudo vi /etc/aliases# root宛てのメールを特定の一般ユーザーに転送
root: your_usernamesudo newaliasesこれにより、Postfixが /root ディレクトリにアクセスする必要がなくなり、安全な運用のまま不具合が解消されます。
第6章：管理者のためのSELinux判断チャート
新しいエラーが発生した場合は、以下のフローに沿って対処を検討します。