audit2allowを使うべきケース・使ってはいけないケース【SELinux運用の分岐点】

SELinuxのトラブル対応で頻繁に登場する audit2allow。

便利な反面、使い方を誤ると 「SELinuxを形骸化させる最短ルート」にもなります。

本記事では、audit2allowを 使うべきケース / 使ってはいけないケースを明確に分け、 安全な判断基準を解説します。

audit2allowとは何か

audit2allow は、AVCログを元に SELinuxポリシーを自動生成するツールです。

「拒否された → 許可する」という流れを コード化してくれます。

audit2allowの基本動作

ausearch -m AVC -ts recent | audit2allow

出力例：

allow httpd_t postgresql_port_t:tcp_socket name_connect;

この1行が持つ意味を理解せず適用するのは非常に危険です。

使う前に必ず考えるべきこと

• 本当に許可すべきアクセスか
• 恒久的な設計として正しいか
• 別の方法で解決できないか

audit2allowを使うべきケース

① 独自アプリ・独自バイナリの場合

以下のようなケースでは有効です。

• 自社開発アプリ
• サードパーティ製バイナリ
• 標準ドメインに当てはまらない処理

既存のBooleanやタイプでは表現できないため、 ポリシー追加が合理的です。

② 明確に限定された操作のみ許可したい場合

必要最小限のAVCだけを精査して 限定的なポリシーを作成する場合です。

audit2allowを使ってはいけないケース

① httpdやmysqldなど標準サービス

標準サービスは、

• Boolean
• ポートタイプ
• ファイルコンテキスト

で解決できるよう設計されています。

audit2allowで許可するのは設計ミスです。

② 原因を理解せず「とりあえず通す」場合

この使い方は最も危険です。

• 不要な権限まで許可
• 将来の脆弱性
• 原因不明の挙動

③ 一時対応のつもりが恒久化される場合

一時的な障害対応で作ったポリシーが、 本番に残り続けるケースは非常に多いです。

安全なaudit2allowの使い方（最低限）

① ログを絞る

ausearch -m AVC -ts today

② 内容を人間が理解する

出力された allow ルールを 必ず1行ずつ読むこと。

③ モジュールとして分離する

ausearch -m AVC -ts recent | audit2allow -M mypolicy
semodule -i mypolicy.pp

audit2allowより優先すべき解決策

• setsebool
• semanage port
• semanage fcontext
• restorecon

判断フローチャート（実務版）

1. 標準サービスか？ → Yes → audit2allowは使わない
2. 独自処理か？ → Yes → 内容を精査
3. 最小権限か？ → Yes → 適用

まとめ

audit2allowは「便利な魔法」ではなく、 最後の手段です。

使う・使わないの判断ができるようになった時、 SELinuxは恐怖の対象ではなくなります。