MajorLinux
6592eb4fea
- Fixed 4 broken markdown links (bad relative paths in See Also sections) - Corrected n8n port binding to 127.0.0.1:5678 (matches actual deployment) - Updated SnapRAID article with actual majorhome paths (/majorRAID, disk1-3) - Converted 67 Obsidian wikilinks to relative markdown links or plain text - Added YAML frontmatter to 35 articles missing it entirely - Completed frontmatter on 8 articles with missing fields Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
96 lines
2.7 KiB
Markdown
96 lines
2.7 KiB
Markdown
---
|
|
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
|