第5章 SELinux 関連の問題のトラブルシューティング
SELinux が無効になっていたシステムで SELinux を有効にする場合や、標準以外の設定でサービスを実行した場合は、SELinux がブロックできる状況のトラブルシューティングを行う必要がある可能性があります。ほとんどの場合、SELinux の拒否は、設定間違いによるものになります。
5.1. SELinux 拒否の特定
この手順で必要な手順のみを行います。ほとんどの場合は、ステップ 1 のみを実行する必要があります。
手順
SELinux がシナリオをブロックしたときに、最初に拒否に関する詳細情報を確認するのは
/var/log/audit/audit.log
ファイルとなります。Audit ログのクエリーには、ausearch
ツールを使用します。アクセスを許可する、または許可しないといった SELinux の決定はキャッシュされ、このキャッシュは AVC (アクセスベクターキャッシュ) として知られています。たとえば、メッセージタイプパラメーターにはAVC
およびUSER_AVC
の値を使用します。# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
一致するものがない場合は、Audit デーモンが実行しているかどうかを確認します。実行していない場合は、
auditd
を起動して Audit ログを再確認してから、拒否されたシナリオを繰り返します。auditd
が実行中で、ausearch
の出力に一致がない場合は、systemd
ジャーナルが出力するメッセージを確認してください。# journalctl -t setroubleshoot
SELinux が有効で、Audit デーモンがシステムで実行していない場合は、
dmesg
コマンドの出力で特定の SELinux メッセージを検索します。# dmesg | grep -i -e type=1300 -e type=1400
以上の 3 つを確認しても、何も見つからない場合もあります。この場合、
dontaudit
ルールが原因で AVC 拒否を非表示にできます。一時的に
dontaudit
ルールを無効にし、すべての拒否をログに記録できるようにするには、以下のコマンドを実行します。# semodule -DB
以前の手順で、拒否されたシナリオを再実行し、拒否メッセージを取得したら、次のコマンドはポリシーで
dontaudit
ルールを再度有効にします。# semodule -B
これまでの 4 つのステップをすべて試し、それでも問題が解決しない場合は、SELinux がシナリオをブロックするかどうかを検討してください。
Permissive モードに切り替えます。
# setenforce 0 $ getenforce Permissive
- シナリオを繰り返します。
上記を試しても問題が発生する場合は、SELinux 以外に原因があります。