Description of problem: After upgrading from F33 to F34 Beta SELinux is preventing f2b/f.dropbear from 'watch' accesses on the dossier /var/log/journal/ec1f2eff01f44aa2bebe5f6230eac47b. ***** Plugin catchall (100. confidence) suggests ************************** Si vous pensez que f.dropbear devrait être autorisé à accéder watch sur ec1f2eff01f44aa2bebe5f6230eac47b directory par défaut. Then vous devriez rapporter ceci en tant qu'anomalie. Vous pouvez générer un module de stratégie local pour autoriser cet accès. Do autoriser cet accès pour le moment en exécutant : # ausearch -c "f2b/f.dropbear" --raw | audit2allow -M my-f2bfdropbear # semodule -X 300 -i my-f2bfdropbear.pp Additional Information: Source Context system_u:system_r:fail2ban_t:s0 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/journal/ec1f2eff01f44aa2bebe5f6230eac47b [ dir ] Source f2b/f.dropbear Source Path f2b/f.dropbear Port <Inconnu> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.7-27.fc34.noarch Local Policy RPM selinux-policy-targeted-3.14.7-27.fc34.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.11.9-300.fc34.x86_64 #1 SMP Wed Mar 24 12:06:51 UTC 2021 x86_64 x86_64 Alert Count 2 First Seen 2021-03-26 21:05:38 CET Last Seen 2021-03-26 21:05:38 CET Local ID 716f7a76-7c19-47b9-86fc-9087dcda3799 Raw Audit Messages type=AVC msg=audit(1616789138.913:525): avc: denied { watch } for pid=814 comm="f2b/f.dropbear" path="/var/log/journal/ec1f2eff01f44aa2bebe5f6230eac47b" dev="sda2" ino=168932 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir permissive=0 Hash: f2b/f.dropbear,fail2ban_t,var_log_t,dir,watch Version-Release number of selected component: selinux-policy-targeted-3.14.7-27.fc34.noarch Additional info: component: selinux-policy reporter: libreport-2.14.0 hashmarkername: setroubleshoot kernel: 5.11.9-300.fc34.x86_64 type: libreport
*** 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.
*** Bug 1943697 has been marked as a duplicate of this bug. ***
With Fedora 36 Fedora Server Edition beta candidate 1.2 (published 22-03-19) I get the same Error in cockpit SELinux tool SELinux is preventing f2b/f.sshd from watch access on the directory /run/log/journal. SELinux is preventing f2b/f.sshd from watch access on the directory /var/log/journal/93bf74be10504548ac7b4c978a9dcb7d. Immediately after a reboot (after installing fail2ban and libvirt) prior to any other action (than access Cockpit)
I got same errors as Peter Boy after performing a DNF System Upgrade to Fedora 36. I had no problems on Fedora 35 before the upgrade. New errors: SELinux is preventing f2b/f.sshd from watch access on the directory /run/log/journal SELinux is preventing f2b/f.sshd from watch access on the directory /var/log/journal SELinux is preventing f2b/f.sshd from watch access on the directory /var/log/journal/f487...
Please see https://bodhi.fedoraproject.org/updates/FEDORA-2022-33c51827f4