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

Switching the component as fail2ban ships its custom policy module.

This interface call needs to be added for f34 and later builds:

optional_policy(`
\tlogging_watch_generic_log_dirs(fail2ban_t)
')

$DAYJOB is killing me right now. Could you provide the update in the form of a patch? Or even better a PR on Rawhide and I'll merge down to F34.

Richard,

No problem with the PR. I would have already done it, I had actualy cloned https://github.com/fail2ban/fail2ban.git before, withou success, but the selinux policy files seem to be in https://src.fedoraproject.org/rpms/fail2ban/tree/rawhide, right?

Yes, sorry I meant to get back to this and now I have several BZs for this, dang it.

https://src.fedoraproject.org/rpms/fail2ban/blob/rawhide/f/fail2ban.if

This is a list of requested permissions from the dup bzs:

allow fail2ban_t auditd_log_t:dir watch;
allow fail2ban_t auditd_log_t:file watch;
allow fail2ban_t fail2ban_log_t:file watch;
allow fail2ban_t syslogd_var_run_t:dir watch;
allow fail2ban_t var_log_t:dir watch;

Richard, if you still can't get to these, I will suggest the solution soon.

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

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

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

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

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

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/755

There needs to be an interface added to selinux-policy, the other commit can be then backported to fail2ban.

So for now I should pull those changes into the fail2ban policy? But once your PR makes it into an update I won't need it anymore?

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

FEDORA-2021-0f39cb8d2e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0f39cb8d2e

FEDORA-2021-0f39cb8d2e has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-0f39cb8d2e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0f39cb8d2e

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

After installing the update I still get these:

type=AVC msg=audit(1623327223.709:6536): avc:  denied  { watch } for  pid=118968 comm="fail2ban-server" path="/var/log/secure" dev="dm-0" ino=662190 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0
type=AVC msg=audit(1623327223.713:6537): avc:  denied  { watch } for  pid=118968 comm="fail2ban-server" path="/var/log/httpd" dev="dm-0" ino=658553 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1623327223.713:6538): avc:  denied  { watch } for  pid=118968 comm="fail2ban-server" path="/var/log/httpd/access_log" dev="dm-0" ino=662142 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=file permissive=0

These come from local configs that detect brute-force attacks on a webapp and my dovecot IMAP server. I imagine many users may have similar configurations.

Zdenek, does the SELinux policy update that got merged address Paul's issues?

I've just sent a PR to backport the change to f2b distgit:
https://src.fedoraproject.org/rpms/fail2ban/pull-request/3

Note selinux-policy-34.9-1 or newer is required, the build dependency may also be added to the specfile.

Since fail2ban ships its own policy of the same name, but installed with higher priority, the fix actually only needs to be applied there (see #c12).

Also sorry I've mistakenly set this bz resolved by selinux-policy update which is not true, just a prerequisite.

I'm using fail2ban-0.11.2-6.fc34 from updates-testing and that fixed lots of issues but left the ones from Comment #17.

Also selinux-policy-34.11-1.fc34.

I worked around the issues using local policy but these look rather over-permissive for what fail2ban needs:

apache_manage_log(fail2ban_t)
logging_manage_generic_logs(fail2ban_t)

(In reply to Paul Howarth from comment #17)
> After installing the update I still get these:
> 
> type=AVC msg=audit(1623327223.709:6536): avc:  denied  { watch } for 
> pid=118968 comm="fail2ban-server" path="/var/log/secure" dev="dm-0"
> ino=662190 scontext=system_u:system_r:fail2ban_t:s0
> tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1623327223.713:6537): avc:  denied  { watch } for 
> pid=118968 comm="fail2ban-server" path="/var/log/httpd" dev="dm-0"
> ino=658553 scontext=system_u:system_r:fail2ban_t:s0
> tcontext=system_u:object_r:httpd_log_t:s0 tclass=dir permissive=0
> type=AVC msg=audit(1623327223.713:6538): avc:  denied  { watch } for 
> pid=118968 comm="fail2ban-server" path="/var/log/httpd/access_log"
> dev="dm-0" ino=662142 scontext=system_u:system_r:fail2ban_t:s0
> tcontext=system_u:object_r:httpd_log_t:s0 tclass=file permissive=0
> 
> These come from local configs that detect brute-force attacks on a webapp
> and my dovecot IMAP server. I imagine many users may have similar
> configurations.
Paul,
I am sorry, I haven't noticed the additional comments.

(In reply to Richard Shaw from comment #18)
> Zdenek, does the SELinux policy update that got merged address Paul's issues?
Richard,
I'd leave it up to your decision: IMO /var/log/secure should definitely be allowed, regarding httpd I cannot assess: it can be seen as common configuration or user adjustment, in the latter case we usually suggest to create a local policy.

For the former one, on the other hand, the approach can even be more general, allowing the access to any file and directory with a SELinux type which is a part of the logfile attribute, i. e. to almost all (if not all) log files/dirs.

(In reply to Paul Howarth from comment #20)
> I'm using fail2ban-0.11.2-6.fc34 from updates-testing and that fixed lots of
> issues but left the ones from Comment #17.
> 
> Also selinux-policy-34.11-1.fc34.
> 
> I worked around the issues using local policy but these look rather
> over-permissive for what fail2ban needs:
> 
> apache_manage_log(fail2ban_t)
> logging_manage_generic_logs(fail2ban_t)
You are right: as a workaround it is acceptable, but it is overpermissive.

FEDORA-2021-0f39cb8d2e has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days