Files

MajorLinux 6592eb4fea wiki: audit fixes — broken links, wikilinks, frontmatter, stale content (66 files)

- 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>

2026-04-02 11:16:29 -04:00

2.7 KiB

Raw Blame History

title, domain, category, tags, status, created, updated

title

domain

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
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

2.7 KiB Raw Blame History