--- title: "SELinux: Fixing Fail2ban grep execmem Denial on Fedora" domain: selfhosting category: security tags: [selinux, fail2ban, fedora, execmem, security] status: published created: 2026-04-02 updated: 2026-04-02 --- # 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`: ```bash 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: ```bash semodule -l | grep fail2ban-grep # Expected: my-fail2ban-grep ``` Check that no new AVC denials appear after restarting fail2ban: ```bash 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 - `ausearch` returns 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)](../../05-troubleshooting/docker-caddy-selinux-post-reboot-recovery.md) — another SELinux fix for post-reboot service issues - [SELinux: Fixing Dovecot Mail Spool Context](../../05-troubleshooting/selinux-dovecot-vmail-context.md) — custom SELinux context for mail spool