SELinux + logrotate + prerotate = 權限被拒絕

我有一個（應該）相當簡單的任務：在晚上將一組自定義日誌文件遷移到數據庫。

我將 logrotate (cron.daily) 與一個簡單的 prerotate 任務一起使用

/var/log/myapplog/*.log
{
   daily
   copytruncate
   rotate 366
   dateext
   dateformat .%Y-%m-%d
   compress
   missingok
   compresscmd /usr/bin/xz
   compressoptions -ze9
   compressext .xz
   prerotate
       /usr/local/myapp/bin/DBWriter $1
   endscript
}

不幸的是，SELinux 不這麼看。如果我setenforce 0那麼腳本執行完美。旋轉日誌，將它們發送到數據庫等 setenforce 1，但是，返回：

logrotate_script: line 1: /usr/local/myapp/bin/DBWriter: Permission denied

我已經嘗試在 DBWriter 上更改上下文，最近我將其設置為unconfined_u:unconfined_r:unconfined_t也不起作用…

理想情況下，我需要啟用 SELinux。如果重要，DBWriter 也可以作為 java .jar 文件使用。但是跑步java -jar DBWriter.jar的結果是一樣的。

提前致謝！

---

編輯：Win.T 下面的回答為我解決了這個問題。

semanage permissive -a logrotate_t

部分問題是我試圖做SELinux旨在防止的事情：導致程序 A 執行未知文件 B 並對系統 C 造成嚴重破壞

項目設計考慮和限制使我們走上了這條道路。

客戶並不總是希望聽到諸如安全性和麵向未來的那些花哨的流行語。

看看/var/log/messages和/var/log/audit/audit.log（如果你有auditd跑步）。您還可以使用audit2allow查看 SELinux 錯誤消息和可能的解決方案。

此外，請嘗試semanage permissive -a logrotate_t允許 logrotate 執行並且不被 SELinux 拒絕。

如果您不確定它是 SELinux，首先嘗試暫時禁用 SELinux 強制執行sudo setenforce 0 SELinux Ref並執行失敗的程式碼。如果是 SELinux，請繼續閱讀。

我最近遇到了這個問題，並且對 SELinux 非常不熟悉，所以這對我來說有點學習曲線。chmod與使用&的(DAC) 標準 posix 模式權限不同chown，SELinux 的權限更加精細。在某些情況下，它會拒絕特定操作，例如通過 TCP/443 連接到網際網路，或允許寫入 /foo 和 /bar，但不允許寫入其他地方等，具體取決於呼叫者（應用程序）。

查看文件（MAC）強制訪問控制權限ls -Z或使用者id -Z輸出user:role:type:level格式。

在 Centos7 上，我在 logrotate.d conf 文件中呼叫了一個腳本，該腳本帶有一個 prerotate 腳本，該腳本將在旋轉之前上傳一個日誌文件。我有幾個否認（登錄到/var/log/audit/audit.log）。我了解到您可以使用一些工具來生成要安裝的特定策略包。我正在為我們的程式碼創建 .rpm 包，因此我將以下所有步驟添加到 .spec 文件中，以在安裝期間生成和安裝策略包。

你需要什麼： policycoreutils-python、checkpolicy（可能已經安裝）

據我了解，如果您計劃分發此安全策略，您的想法是您只想發送 *.te 文件並在現場生成策略，因此如果策略所依賴的定義得到更新，它們將在安裝時被繼承。

#查找拒絕消息

watch "tail /var/log/audit/audit.log | grep 'denied'"

# 創建 te（類型強制）文件（人類可讀的安全策略）

grep 1561055176.928:11371 /var/log/audit/audit.log|audit2allow -m myapp > myapp.te

# 你也可以 grep 一些失敗並將它們全部傳遞給 audit2allow

cat /var/log/audit/audit.log | grep logrotate | audit2allow -m myapp > myapp.te

# 你也可以使用 audit2why 來稍微解釋一下為什麼它有時會通過修復步驟失敗

cat /var/log/audit/audit.log | grep logrotate | audit2why

警告在此步驟中，我發現 audit2why 報告我的腳本會在我執行時起作用setsebool -P nis_enabled 1。雖然這聽起來不錯而且很花哨，但您應該始終查找執行這些命令的安全隱患。設置它可能會擴大你的攻擊面，所以使用者要小心。

# 從類型強製文件建構一個策略模組

checkmodule -M -m -o myapp.mod myapp.te

# 從策略模組建構策略包

semodule_package -o myapp.pp -m myapp.mod

# 使用 root privs 載入策略包

semodule -i myapp.pp

我不得不多次執行這些步驟，直到我積累了我的程式碼執行所需的所有微小權限。

• 更新 -

我最終在 logrotate cron 任務之前內聯執行了我的腳本，這樣我就不必擴展 logrotate_t 的權限。我將它放在 prerotate 中，因為我不想在失敗時旋轉文件，這種語法仍然滿足。如果第一個命令失敗，使用 ‘&&’ 語法將不會執行第二個命令。

10 * * * * root /usr/bin/sudo -i -u otheruser /opt/send_logs.sh && /usr/sbin/logrotate -f /path/to/myapp_logrotate.conf > /tmp/myapp_rotate.log 2&1

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