資深菜鳥工程師又來發問了。
工作環境在安裝 Linux 時都會啟用 audit.log ，一直以來也都很順利的運作，不過前一陣子在安裝 Rocky Linux 8 時，不確定是那個版本的問題 (目前是 8.8) ，會發生 audit.log 無法寫入的問題，這邊的環境會要求開啟 SELinux ，所以若是有發生 AVC Denial 問題，都靠 audit.log 來分析解決，現在 audit.log 無法寫入，雖然在 messages 裡也有相類似的訊息，但似乎無法直接使用，因為多次處理 AVC 事件的經驗，印象中大概知道是什麼原因，rsyslogd_t 對於 audit_log_t 沒有寫入權限，不譮是 file 或是 dir ，有試著自己造假訊息，然後去產生解決方案，有的可以解決，但是今天用這個解決方案卻完全無效，直到把 SELinux 關掉重開機，讓 log 可以正常寫入後再開啟 SELinux 後重開機才得以正常寫入。
不知道這是什麼原因造成的，有查看過版本比較舊一點的 Rocky ，也沒有上述的的規則，audit.log 也都能正常寫入，而且用產生假的 AVC 訊息來產生解決方案，似乎也不是辦法。
謝謝！
已邀請的邦友 {{ invite_list.length }}/5
那是因為 /var/log/audit/audit.log 預設是只允許 auditd 這個服務來使用, 所以如果你是用官方標準套件安裝的話, 為了避免被其他惡意程式截取其內的敏感內容, SELinux 的預設規則是不允許其他人來存取這個檔案.
你用 ausearch 找出 AVC 製作臨時的 .pp 匯入 semodule, 只能暫時解決當下的問題. 但是 rsyslog 存取 audit.log 的 class 種類很多 (大約有下面六種 class), 你這樣臨時改, 無法一次就涵蓋掉全部六種樣態, 只要漏掉一種沒寫, 下次又會被擋住.
要完全解決這個問題, 必須自己撰寫 SELinux Policy (自行建立一個 rsyslog.te 檔案):
module rsyslog2auditpol 1.0;
require {
type syslogd_t;
type auditd_log_t;
class file read;
class file ioctl;
class file open;
class file getattr;
class dir search;
class dir getattr;
}
#============= syslogd_t ==============
allow syslogd_t auditd_log_t:file read;
allow syslogd_t auditd_log_t:file ioctl;
allow syslogd_t auditd_log_t:file open;
allow syslogd_t auditd_log_t:file getattr;
allow syslogd_t auditd_log_t:dir search;
allow syslogd_t auditd_log_t:dir getattr;
然後把它匯入 SELinux module:
checkmodule -M -m -o rsyslog.mod rsyslog.te
semodule_package -o rsyslog.pp -m rsyslog.mod
semodule -i rsyslog.pp
此外, 如果臨時要關掉 SELinux, 可以用:
setenforce 0
不需要重開機就能生效; 後面改回 1 就又啟動 SELinux.
或者, 你也可以查詢目前的 SELinux 狀態:
getenforce
謝謝大神回答，又學到了。
我做的假 AVC 事件，其實有包含那六大項，其實有多。
會用改 config 再重開機也是因為用 setenforce 的方式沒有效，真奇怪，不過這點我會再注意，也有可能是因為「急著解決問題」而疏忽了。
不好意思，我另外好奇的是，印象中 Rocky 8.6 之前的版本都沒有這個問題，有台主機我檢查了，並沒有 rsyslogd_t audit_log_t 的規則，但是 audit.log 的寫入是正常的，所以到最近才發現有這個問題。
再次感謝！
我剛找了一台標準安裝的 8.8 來看，似乎沒有你提到的問題, 而且 setenforce 也可以正常關掉 SELinux.
由此推論, 你這台 8.8 很可能設定了其他的客製參數, 導致他的行為已經跟標準的版本不同了. 該不會是....你上了政府單位給 RedHat 用的 GCB 基準設定?
真不好意思！還讓您動手執行了一遍。
是的，套用了政府的 GCB (因為駐點在政府單位)，看來要找時間研究一下，到底是那條造成的，要嘛不套用，要嘛就加上 rsyslogd_t 的這個規則。
再次感謝！
GCB 總共有 290 幾條, 希望你能多遇到幾個颱風假可以慢慢看...^D
(哀, 應該要跟技服中心商量一下, 別設這麼嚴格....但我認識的人都已經走了...)
報告大神，因為這陣子新安裝主機都是我在套用 GCB ，再加上大神幫我試了原裝是沒有問題的，所以心中概有了個底，剛剛測試出來問題所在。
GCB 第 140 條，要求要把 /var/log/audit 這個目錄把原本的 700 改成 600 或更低，我就依照建議改成 600 ，重開機後就發現 audit.log 寫不進去了，若是忽略這一條，自己認為可能有影響的規則套用後重開機，仍然可以寫入，所以應該就是這條造成的。
最近要裝五台主機，再來觀察這條不套用的話，會不會再發生。
再次感謝！
原來是我完全搞錯方向、問題，真正的問題是 auditd 的服務起不來，所以 audit.log 才會沒有東西寫進去。
嘆～～～～
我真的太菜了。
目前找到的解決方法：
dnf reinstall audit
systemctl reset-failed auditd.service
systemctl start auditd.service
然後，audit.log 就開始寫東西了，根本跟什麼 700 600 無關。
雖然那個 AVC 事件也是確有其事，但並不影響 audit log 的寫入，只影響 rsyslog 的寫入。
iThome鐵人賽
看影片追技術