Kevin,

Please attach the output of

  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Switching the component as fail2ban ships its own policy.

Here is the output:

----
type=PROCTITLE msg=audit(06/24/2022 16:11:28.590:966) : proctitle=/usr/bin/python3 -s /usr/bin/fail2ban-server -xf start 
type=SYSCALL msg=audit(06/24/2022 16:11:28.590:966) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7fa62bffd990 a2=0x1000386 a3=0x9 items=0 ppid=1 pid=13256 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=f2b/f.sshd exe=/usr/bin/python3.9 subj=system_u:system_r:fail2ban_t:s0 key=(null) 
type=AVC msg=audit(06/24/2022 16:11:28.590:966) : avc:  denied  { watch } for  pid=13256 comm=f2b/f.sshd path=/run/log/journal dev="tmpfs" ino=58 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 
----
type=PROCTITLE msg=audit(06/24/2022 16:11:28.590:967) : proctitle=/usr/bin/python3 -s /usr/bin/fail2ban-server -xf start 
type=SYSCALL msg=audit(06/24/2022 16:11:28.590:967) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7fa62bffd910 a2=0x1002fc6 a3=0xc items=0 ppid=1 pid=13256 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=f2b/f.sshd exe=/usr/bin/python3.9 subj=system_u:system_r:fail2ban_t:s0 key=(null) 
type=AVC msg=audit(06/24/2022 16:11:28.590:967) : avc:  denied  { watch } for  pid=13256 comm=f2b/f.sshd path=/run/log/journal/5b5b1df497254580be34dc64b37be4e5 dev="tmpfs" ino=454 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 
----
type=PROCTITLE msg=audit(06/24/2022 16:11:28.591:968) : proctitle=/usr/bin/python3 -s /usr/bin/fail2ban-server -xf start 
type=SYSCALL msg=audit(06/24/2022 16:11:28.591:968) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7fa62bffd910 a2=0x1002fc6 a3=0xc items=0 ppid=1 pid=13256 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=f2b/f.sshd exe=/usr/bin/python3.9 subj=system_u:system_r:fail2ban_t:s0 key=(null) 
type=AVC msg=audit(06/24/2022 16:11:28.591:968) : avc:  denied  { watch } for  pid=13256 comm=f2b/f.sshd path=/run/log/journal/ffffffffffffffffffffffffffffffff dev="tmpfs" ino=59 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 
----
type=PROCTITLE msg=audit(06/24/2022 16:11:32.800:1063) : proctitle=/usr/bin/python3 -s /usr/bin/fail2ban-server -xf start 
type=SYSCALL msg=audit(06/24/2022 16:11:32.800:1063) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7f75051df990 a2=0x1000386 a3=0x9 items=0 ppid=1 pid=13512 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=f2b/f.sshd exe=/usr/bin/python3.9 subj=system_u:system_r:fail2ban_t:s0 key=(null) 
type=AVC msg=audit(06/24/2022 16:11:32.800:1063) : avc:  denied  { watch } for  pid=13512 comm=f2b/f.sshd path=/run/log/journal dev="tmpfs" ino=58 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 
----
type=PROCTITLE msg=audit(06/24/2022 16:11:32.801:1064) : proctitle=/usr/bin/python3 -s /usr/bin/fail2ban-server -xf start 
type=SYSCALL msg=audit(06/24/2022 16:11:32.801:1064) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7f75051df910 a2=0x1002fc6 a3=0xc items=0 ppid=1 pid=13512 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=f2b/f.sshd exe=/usr/bin/python3.9 subj=system_u:system_r:fail2ban_t:s0 key=(null) 
type=AVC msg=audit(06/24/2022 16:11:32.801:1064) : avc:  denied  { watch } for  pid=13512 comm=f2b/f.sshd path=/run/log/journal/5b5b1df497254580be34dc64b37be4e5 dev="tmpfs" ino=454 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 
----
type=PROCTITLE msg=audit(06/24/2022 16:11:32.801:1065) : proctitle=/usr/bin/python3 -s /usr/bin/fail2ban-server -xf start 
type=SYSCALL msg=audit(06/24/2022 16:11:32.801:1065) : arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7f75051df910 a2=0x1002fc6 a3=0xc items=0 ppid=1 pid=13512 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=f2b/f.sshd exe=/usr/bin/python3.9 subj=system_u:system_r:fail2ban_t:s0 key=(null) 
type=AVC msg=audit(06/24/2022 16:11:32.801:1065) : avc:  denied  { watch } for  pid=13512 comm=f2b/f.sshd path=/run/log/journal/ffffffffffffffffffffffffffffffff dev="tmpfs" ino=59 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0

This looks similar to something Orion fixed in rawhide but I'm not sure if it's made it into an EPEL build...

https://src.fedoraproject.org/rpms/fail2ban/c/ec52ec24716b4d6e820431dbe7b33aceb20112d0?branch=rawhide

That looks similar but the problem was resolved by allowing watch on syslogd_var_run_t:dir.  Fail2ban uses the systemd journal and not files in /var/log.

Here is the content of my-f2bfsshd.te that resolved the issue for me:

module my-f2bfsshd 1.0;

require {
        type syslogd_var_run_t;
        type fail2ban_t;
        class dir watch;
}

#============= fail2ban_t ==============
allow fail2ban_t syslogd_var_run_t:dir watch;

The systemd journal files are in /var/log/journal.  Is it different in RHEL?

I do have a /var/run/log/journal directory on my F36 system, but it's empty and unowned, so I have no idea where it came from.  I'm guessing it's a leftover from some previous release.

From the man page for systemd-journald:

       The journal service stores log data either persistently below
       /var/log/journal or in a volatile way below /run/log/journal/ (in the
       latter case it is lost at reboot). By default, log data is stored
       persistently if /var/log/journal/ exists during boot, with an implicit
       fallback to volatile storage otherwise. Use Storage= in
       journald.conf(5) to configure where log data is placed, independently
       of the existence of /var/log/journal/.

On a fresh install of AlmaLinux 9 (or RHEL 9) it will perform volatile logging as mentioned above.  In addition, rsyslog monitors the journal and persistently logs some of the data to various log files in /var/log.

Samuel, I assume you have an older or perhaps a modified configuration.

I think you misunderstood my comment.  My logs are in the standard /var/log/journal.  I just realized while writing this why there is an empty /var/run/log/journal directory.  /var/run is symlinked to /run.

But I was also being misled by the selinux type which says "syslogd_**var_run**_t" and missed that the indicated directory is actually "/run/log" and now that I discovered the symlink, that makes more sense.

Kevin, do you still see this problem? If you just install fail2ban, I expect you do.

If so, does installing the additional fail2ban-selinux package resolve it for you? I believe it would, but, I wasn't able to find anything that states that it's required for fail2ban to actually work.

I'd suspect that the most common use case for fail2ban would be brute force protection for SSH, it's a bit of a problem that it will silently fail to do that without installing an additional package that you wouldn't know about without looking for it.

I think it makes sense to make fail2ban-selinux a dependency to fail2ban.

Currently the selinux package is only installed on Fedora. I admit I don't have time to keep up with the EL stuff, so it looks like it is needed on EL9?

I can update:
%if 0%{?fedora}
Requires: (%{name}-selinux if selinux-policy-%{selinuxtype})
%endif

To:
%if 0%{?fedora} || 0%{?rhel} >= 9
Requires: (%{name}-selinux if selinux-policy-%{selinuxtype})
%endif

Dan, I did a fresh install of AlmaLinux 9, updated all the packages, and only installed fail2ban.  With just that package it did seem to exhibit the same problem.  I installed fail2ban-selinux and it appears to fix it.  I tried to look at the the policy in that package.  While it has a lot of rules in there, it did seem to include watch on syslogd_var_run_t.  It looks like installing fail2ban-selinux does fix the issue.

Since SELinux is enabled by default, it would make sense to require fail2ban-selinux when installing fail2ban.

I added EL 9 to the conditional for requiring the selinux subpackage.

If it's OK I'd like to close this as "next release". I'm still working on the iptables vs nftables problem and would prefer to wait until I have a fix for that before doing builds.

I'm ok with waiting on it but I have already worked around it.

*** Bug 2095722 has been marked as a duplicate of this bug. ***

FEDORA-EPEL-2023-07bf30a1f1 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-07bf30a1f1

FEDORA-EPEL-2023-07bf30a1f1 has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-07bf30a1f1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2023-07bf30a1f1 has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.