第5章 SELinux 関連の問題のトラブルシューティング
SELinux が無効になっていたシステムで SELinux を有効にする場合や、標準以外の設定でサービスを実行した場合は、SELinux がブロックできる状況のトラブルシューティングを行う必要がある可能性があります。ほとんどの場合、SELinux によるアクセス拒否は設定ミスを示していることに注意してください。
5.1. SELinux 拒否の特定 リンクのコピーリンクがクリップボードにコピーされました!
監査ログから Access Vector Cache (AVC) 拒否メッセージを検索することで、SELinux に関連する問題を特定します。AVC ログを確認することで、SELinux が意図した操作をブロックしているかどうかを迅速に判断できます。
SELinux がシナリオをブロックしたときに、最初に拒否に関する詳細情報を確認するのは /var/log/audit/audit.log ファイルとなります。Audit ログのクエリーには、ausearch ツールを使用します。
この手順で必要な手順のみを行います。ほとんどの場合は、ステップ 1 のみを実行する必要があります。
手順
アクセスを許可する、または許可しないといった 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 setroubleshootSELinux が有効で、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 以外に原因があります。