SELinuxは、新しいRHEL7サーバー展開に移行する際の運用上の問題を防ぐのに役立つ許可モードです。いくつかのSELinuxの問題は確認して解決するのが非常に簡単ですが、次の問題は少し混乱しています。
AVCは次のとおりです。
type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
監査2が言う理由は次のとおりです。
type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
Audit2allowは次のように言いました。
#============= postfix_postdrop_t ==============
#!!!! The file '/var/spool/postfix/public/pickup' is mislabeled on your system.
#!!!! Fix with $ restorecon -R -v /var/spool/postfix/public/pickup
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;
この通知は、次のコマンドを実行して問題の一部を修正する必要があることを意味するようです。
# restorecon -R -v /var/spool/postfix/public/pickup
# ls -lZ /var/spool/postfix/public/pickup
srw-rw-rw-. postfix postfix unconfined_u:object_r:postfix_public_t:s0 /var/spool/postfix/public/pickup
ただし、SELinux監査ロギングの問題は完了後も変更されたようには見えないため、明らかにより多くの作業を行う必要があります。おそらく、いくつかの問題は仲裁に関連しているでしょう。
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;
postfixと同じくらい確立されたサービスに管理者の介入が必要なSELinuxの問題があることは奇妙です。
この問題の解決策は次のとおりです。
# echo 'type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
| audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp
しかし、そのような変更が正当であると考えられる理由についてのより良い理解なしに、単に監査問題を取り除くための措置を講じることは賢明ではないようです。
これは本当にタグの問題ですか、それとも単に「許容」不足による副作用ですか?そして、これがPostfixインストールがスムーズに実行されるために管理者が行う必要がある合法的で予想される変更であることについて誰でもコメントできますか? SELinux?
SELinuxをオフにすることを提案しないでください。もちろんオプションですが、むしろこれを守る方法を学び、このような性格の問題が生じたときに正しい行動方針を見分ける方法を学びたいと思います。
注:上記のコマンドaudit2allow -M ..
とsemanage -i
コマンドはラベルを再指定せずにSELinuxの問題を解決しますが、ラベルを再指定するとポリシーを作成する必要がないかどうかはわかりません。この方法で問題を解決することが期待されるのか、それとも正常であるのかはわかりません。
#============= postfix_postdrop_t ==============
#!!!! This avc is allowed in the current policy
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;
答え1
実際にrestorecon
使用後のSELinuxの問題を解決するために、これらのコマンドはもはや必要ありません。
# echo 'type=AVC msg=audit(1533595368.668:140747): avc: denied { connectto } for pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
| audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp
以下は、SELinux監査の問題を解決するのに役立つことを望む理由です。
緩和段階の前の種類を参照してください。この場合:
unix_stream_socket
残念ながら理解を助けるため、コマンドを実行する
ls -lZ /var/spool/postfix/public/pickup
前に実行しませんでした。restorecon
ヒント:変更する前にSELinuxコンテキストを確認してください。
restorecon -R -v /var/spool/postfix/public/pickup
実行後のSELinuxタイプを参照してください。suffix_public_t
ジャンルが変わることは注目に値する。
ヒント:推奨
restorecon
コマンドと個々のallow
ルールの両方が一覧表示されている場合、緩和提案が代替ソリューション(どちらでも問題を解決する)になる可能性が低くなります。audit2allow
出力が変更され、提案されたコマンドrestorecon
はもう存在しません。audit2allow
出力に両方のコマンドが含まれ、変更がrestorecon
1つだけ含まれてrule
いる場合。restorecon
ここで重要なのは、rule
使用されなくなったタイプのルールを作成する理由がなくなったため、AVCの表示がもはや関連していないことを認識することです。postfix_postdrop_t
たとえば、この特別なケースでは、ソケットが最上位にある場合にアクセス権を付与する理由はありません。unix_stream_socket
postfix_public_t
他の同様の状況では、AVCはそれ自体が歴史的な出来事だったことを覚えておくことが重要です。 AVCは歴史的なインシデントのためであるため、代替ソリューションの詳細がイベントの時点でのシステム状態ともはや同じでない場合は、古い問題に対する代替ソリューションが不要になる可能性があることに注意してください。つまり、このコマンドを使用すると、restorecon
提案が存在しなくなったときに「現在のポリシーで許可されている」というメッセージを期待する必要はありません。restorecon
この2つの軽減方法を使用しないことが賢明であるかどうか疑問に思っている場合は、実際にこの2つの緩和方法が必要な場合は、今後の監査イベントが発生することを確認してください。
実際に複数の緩和を使用しない場合、付随的な利点があります。 SELinuxの全体的な目的は、プロセスが実際に必要なものにアクセスできないように制限することです。不要なタイプの強制変更が行われた場合、postfix_postdrop_t
実行可能ファイルはunix_stream_socket
runに関連付けられていない他のリソースにアクセスすることに制限されず、postfix
正当なランタイム制約がpostfix
壊れます。
この質問のより適切なタイトルは次のとおりです。audit2allowが復元とルールの変更を提案した場合、両方の緩和策が必要ですか?」