當 audit2allow 建議 restorecon 和一種類型的強制規則時，是否需要這兩種緩解措施？

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

audit2why 說：

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 審計記錄的問題在完成後似乎沒有改變，因此，顯然還有更多工作要做。據推測，其中一些問題與 audit2allow 提及有關：

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。當然，這是一種選擇，但我更願意學習如何讓它保持開啟狀態，並學習如何在出現這種性質的問題時辨識正確的行動方案。A

注意：上述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;

事實上，自從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 上下文。

• 注意執行後的 SELinux 類型restorecon -R -v /var/spool/postfix/public/pickup：

postfix_public_t

重要的是要注意確實發生了類型更改。

提示：當列出建議的restorecon命令和單個allow規則時，緩解建議不太可能是替代解決方案（其中一個，不是兩個，都可以解決問題）。

• 請注意，audit2allow輸出已更改，因此建議的restorecon命令不再存在。

當audit2allow輸出同時包含一個restorecon命令且只有一個rule更改時，在使用 進行緩解嘗試後restorecon，問題很可能已解決。這裡的關鍵是要意識到rule為 AVC 顯示的內容不再相關，因為不再有任何理由要求關於不再使用的類型的規則。

例如，在這種特定情況下，postfix_postdrop_t當unix_stream_socket該套接字現在具有postfix_public_t.

在任何其他類似的情況下，重要的是要記住 AVC 本身是針對歷史事件的。由於 AVC 是針對歷史事件的，因此應該記住，如果替代解決方案中的細節不再與事件發生時的系統狀態相同，則可能不需要舊問題的替代解決方案。換句話說，一旦使用了命令，當建議不再存在restorecon時，就沒有必要期待“在目前策略中允許”消息。restorecon

如果您仍然想知道不使用這兩種緩解措施是否明智，請放心，如果確實需要兩種緩解措施，那麼未來的審計事件將會發生。

不使用多種緩解措施實際上有一個附帶好處。請記住，SELinux 的全部意義在於限制程序訪問它們實際需要的東西。如果進行了不必要的類型強制更改，則可postfix_postdrop_t執行文件不再受限制訪問unix_stream_socket與 running 無關的其他資源postfix，並且合法的執行時約束postfix將被破壞。

這個問題的一個更合適的標題可能是：“當 audit2allow 建議 restorecon 和一個規則更改時，是否需要這兩種緩解措施？ ”

引用自：https://unix.stackexchange.com/questions/460924