SELinuxポリシー設計のアンチパターン集【やってはいけない設計】

SELinuxは正しく設計すれば非常に強力ですが、 設計を誤ると「無効化したくなる存在」になります。

本記事では、現場で繰り返されてきた SELinuxポリシー設計のアンチパターンを紹介し、 なぜそれが危険なのかを解説します。

アンチパターン① とりあえず setenforce 0

概要

障害が出た瞬間に enforcing を無効化する。

なぜ危険か

• 原因が永遠に分からない
• セキュリティ低下
• 戻し忘れ事故

正しい考え方

まず AVC ログを確認し、原因を特定する。

アンチパターン② audit2allowの無差別適用

概要

AVCログを全部ポリシー化する。

なぜ危険か

• 不要な権限まで許可
• 意図しない挙動
• ポリシーがブラックボックス化

正しい考え方

必要な1行だけを精査して適用。

アンチパターン③ chconの常用

概要

すべて chcon で解決しようとする。

なぜ危険か

• 再起動で消える
• restoreconで壊れる
• 設定履歴が残らない

正しい考え方

恒久対応は semanage fcontext。

アンチパターン④ 標準サービスに独自ポリシーを足す

概要

httpd や mysqld に独自 allow を追加。

なぜ危険か

• 設計思想と乖離
• アップデート耐性なし
• 再現性がない

正しい考え方

Boolean・ポート・コンテキストで解決。

アンチパターン⑤ 権限を広げすぎる

概要

必要以上のタイプを付与。

なぜ危険か

• 攻撃面積拡大
• 事故時の影響が大きい

正しい考え方

最小権限の原則を守る。

アンチパターン⑥ 設計ドキュメントがない

概要

誰が何を許可したか分からない。

なぜ危険か

• 属人化
• 保守不能

正しい考え方

ポリシーの意図を必ず残す。

アンチパターン⑦ 運用前提を考えていない

概要

再起動・再デプロイを想定していない。

なぜ危険か

• 障害が再発
• 夜間対応増加

正しい考え方

再起動しても壊れない設計。

アンチパターン⑧ SELinuxを理解していないまま有効化

概要

「とりあえず有効」にする。

なぜ危険か

• トラブル時に詰む
• 結局無効化される

正しい考え方

設計 → 検証 → 本番の順。

安全なSELinux設計のチェックリスト

• 標準機能で解決できるか
• 恒久設定になっているか
• 最小権限か
• 説明できるか

まとめ

SELinuxは「難しい」のではなく、 雑に扱うと壊れるだけです。

アンチパターンを避けるだけで、 SELinuxは「頼れる守り」になります。