SELinux enforcing環境でよくある障害事例集【原因と正しい対処】

URLをコピーしました！

SELinuxを enforcing のまま運用していると、「原因不明の通信エラー」「権限はあるはずなのに動かない」といった障害に必ず直面します。

本記事では、現場で頻発する SELinux enforcing環境特有の障害事例をまとめ、原因・見抜き方・正しい対処を整理します。

事例① firewalldは許可済みだが通信できない

症状

Firewallでポート開放済み
LISTENも確認できる
外部から接続できない

原因

SELinuxが非標準ポート通信を拒否している。

確認

ausearch -m AVC -ts recent

対処

semanage port -a -t http_port_t -p tcp 8080

事例② httpdが外部APIに接続できない

症状

curlは通る
Webアプリからは失敗

原因

httpdの外部通信がBooleanで制限されている。

対処

setsebool -P httpd_can_network_connect on

事例③ ファイル書き込みがPermission deniedになる

症状

chmod/chown済み
それでも書き込み不可

原因

ファイルコンテキストが httpd 書き込み不可。

対処

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/app/data(/.*)?"
restorecon -Rv /var/www/app/data

事例④ 独自バイナリがhttpdから起動できない

症状

手動実行は成功
Web経由だと失敗

原因

httpd_t からの exec 権限がない。

対処

実行ファイル配置見直し
ドメイン設計の再検討

事例⑤ DB接続が突然失敗する

症状

設定変更なし
再起動後に発生

原因

ポート再設定・コンテキスト崩れ。

確認

semanage port -l | grep 5432

事例⑥ audit2allowを使ったら別の障害が出た

症状

一部は動く
予期せぬ挙動

原因

過剰なポリシー許可による副作用。

対処

モジュール削除
設計ベースで再調整

事例⑦ 再起動後に突然アクセス不可

症状

直前まで正常
設定は変えていない

原因

chcon による一時コンテキストが消失。

対処

semanage fcontext -l | grep 対象パス
restorecon -Rv 対象パス

SELinux障害の切り分け共通ルール

getenforce確認
AVCログ確認
コンテキスト確認
Boolean確認

やってはいけない対処

setenforce 0 の放置
無差別 audit2allow
SELinux無効化

まとめ

SELinux enforcing 環境の障害は、 すべて「理由があって止めている」だけです。

事例パターンを知っていれば、恐れる必要はありません。