Fedora Account System
Red Hat Associate
Red Hat Customer
type=AVC msg=audit(1656066390.060:54): avc: denied { watch } for pid=7957 comm="f2b/f.sshd" path="/run/log/journal/488cebb3cf46439fb26be4638cad344d" dev="tmpfs" ino=59 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access.
Another one that only occurs on startup as well. ``` type=AVC msg=audit(1656075020.194:1363373): avc: denied { execmem } for pid=409029 comm="grep" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=process permissive=0 Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated. Possible mismatch between current in-memory boolean settings vs. permanent ones. ``` with the following .te file fail2ban is now working again on CentOS Stream 9. fail2ban-server-0.11.2-12.el9.noarch module fail2ban-syslog 1.1; require { type syslogd_var_run_t; type fail2ban_t; class dir watch; class process execmem; } #============= fail2ban_t ============== allow fail2ban_t self:process execmem; allow fail2ban_t syslogd_var_run_t:dir watch;
There is a bug in the current fail2ban-server packaging where it doesn't bring in the fail2ban-selinux package. If you install that, things should be better. I'll try to get an update out soon.
FEDORA-EPEL-2023-07bf30a1f1 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-07bf30a1f1
FEDORA-EPEL-2023-07bf30a1f1 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-07bf30a1f1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2023-07bf30a1f1 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Steve Traylen from comment #1) > Another one that only occurs on startup as well. > > ``` > type=AVC msg=audit(1656075020.194:1363373): avc: denied { execmem } for > pid=409029 comm="grep" scontext=system_u:system_r:fail2ban_t:s0 > tcontext=system_u:system_r:fail2ban_t:s0 tclass=process permissive=0 > > Was caused by: > Unknown - would be allowed by active policy > Possible mismatch between this policy and the one under > which the audit message was generated. > > > Possible mismatch between current in-memory boolean settings > vs. permanent ones. > ``` > > with the following .te file fail2ban is now working again on CentOS Stream 9. > > > fail2ban-server-0.11.2-12.el9.noarch > > module fail2ban-syslog 1.1; > > require { > type syslogd_var_run_t; > type fail2ban_t; > class dir watch; > class process execmem; > } > > #============= fail2ban_t ============== > allow fail2ban_t self:process execmem; > allow fail2ban_t syslogd_var_run_t:dir watch; I get the same denial still. It does not look like this ever made it into fail2ban.te, did it?
Was "allow fail2ban_t self:process execmem;" not included because fail2ban should not be allowed to use grep in this way, or was this an oversight?
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days