New article: selinux-fail2ban-execmem-fix.md — custom policy module for fail2ban grep execmem denial on Fedora 43. Also includes previously uncommitted: - n8n-proxy-trust-x-forwarded-for.md - fail2ban-apache-404-scanner-jail.md updates Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2.5 KiB
2.5 KiB
SELinux: Fixing Fail2ban grep execmem Denial on Fedora
The Problem
After a reboot on Fedora 43, Netdata fires a selinux_avc_denials WARNING alert. The audit log shows:
avc: denied { execmem } for comm="grep"
scontext=system_u:system_r:fail2ban_t:s0
tcontext=system_u:system_r:fail2ban_t:s0
tclass=process permissive=0
Fail2ban spawns grep to scan log files when its jails start. SELinux denies execmem (executable memory) for processes running in the fail2ban_t domain. The fail2ban-selinux package does not include this permission.
Impact
- Fail2ban still functions — the denial affects grep's memory allocation strategy, not its ability to run
- Netdata will keep alerting on every reboot (fail2ban restarts and triggers the denial)
- No security risk — this is fail2ban's own grep subprocess, not an external exploit
The Fix
Create a targeted SELinux policy module that allows execmem for fail2ban_t:
cd /tmp
cat > my-fail2ban-grep.te << "EOF"
module my-fail2ban-grep 1.0;
require {
type fail2ban_t;
class process execmem;
}
allow fail2ban_t self:process execmem;
EOF
# Compile the module
checkmodule -M -m -o my-fail2ban-grep.mod my-fail2ban-grep.te
# Package it
semodule_package -o my-fail2ban-grep.pp -m my-fail2ban-grep.mod
# Install at priority 300 (above default policy)
semodule -X 300 -i my-fail2ban-grep.pp
Verifying
Confirm the module is loaded:
semodule -l | grep fail2ban-grep
# Expected: my-fail2ban-grep
Check that no new AVC denials appear after restarting fail2ban:
systemctl restart fail2ban
ausearch -m avc --start recent | grep fail2ban
# Expected: no output (no new denials)
Why Not audit2allow Directly?
The common shortcut ausearch -c grep --raw | audit2allow -M my-policy can fail if:
- The AVC events have already rotated out of the audit log
ausearchreturns no matching records (outputs "Nothing to do")
Writing the .te file manually is more reliable and self-documenting.
Environment
- OS: Fedora 43
- SELinux: Enforcing, targeted policy
- Fail2ban: 1.1.0 (
fail2ban-selinux-1.1.0-15.fc43.noarch) - Kernel: 6.19.x
See Also
- Docker & Caddy Recovery After Reboot (Fedora + SELinux) — another SELinux fix for post-reboot service issues
- SELinux: Fixing Dovecot Mail Spool Context — custom SELinux context for mail spool