Description of problem: The following SELinux denial is logged several times upon startup of fail2ban: type=AVC msg=audit(1748686317.733:34516): avc: denied { execmem } for pid=785523 comm="grep" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=process permissive=0 How reproducible: Steps to Reproduce: 1. systemctl start fail2ban 2. Check audit log Additional info: I am not sure what fail2ban does that it wants execmem, so this might be an upstream issue.
Is this not an easy fix? Or is fail2ban not supposed to do this and I should report this upstream?
Couple things: * I cannot reproduce this on my AlmaLinux 9.6 system * execmem is really not something that should ever be enabled or needed So you're going to need to figure out what exactly fail2ban is trying to do here. I also can't really imagine grep ever needing execmem. Do you have a modified grep? rpm -V grep which grep start fail2ban with loglevel = DEBUG and post your fail2ban.log
Unmodified grep, rpm verify comes back clean and the f2b log does not show any errors. It turns out that the denial happens when stopping (or restarting) fail2ban. I have traced this to the nftables banaction. Steps to reproduce: /etc/fail2ban/jail.d/nginx-limit-req.local: ``` [nginx-limit-req] banaction = nftables enabled = true ``` ``` sudo fail2ban-client set nginx-limit-req banip 1.2.3.4 sudo systemctl start fail2ban sudo systemctl stop fail2ban ``` audit.log shows: type=AVC msg=audit(1759651205.377:859): avc: denied { execmem } for pid=18382 comm="grep" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=process permissive=0 The uses of grep in action.d/nftables.conf to remove nftables rules look ok to me, but I'm ready to make an upstream report if you think something should be changed there.