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.
I reproduced it on Fedora 42 as well. After searching up on execmem denials, I tried removing the -P flag from a grep invocation in nftables.conf and indeed, that grep invocation no longer causes a denial message. So I think this is caused by PCRE-JIT, as reports from other software suggest, e.g.: https://github.com/syslog-ng/syslog-ng/issues/2986 https://unix.stackexchange.com/questions/287831/how-to-work-out-why-apache-is-attempting-execmem If this is correct, the question is, should f2b config files avoid "grep -P" or should this be allowed by SELinux? IMO it's probably better to avoid PCRE-JIT here, if possible.