Bug 1983564

Summary: SELinux don't allow to read all log files
Product: [Fedora] Fedora EPEL Reporter: Frank Büttner <bugzilla>
Component: fail2banAssignee: Richard Shaw <hobbes1069>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel8CC: anon.amish, Axel.Thimm, customercare, hobbes1069, orion, vonsch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-02 13:02:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frank Büttner 2021-07-19 06:27:23 UTC
Description of problem:
When I try to monitor my nextcloud instance, which use nfs for data storage, then 
fail2ban can't read the log file

Version-Release number of selected component (if applicable):
fail2ban-server-0.11.2-1.el8.noarch


How reproducible:
Every time

Steps to Reproduce:
1. start fail2ban

Actual results:
The start fails because the log file on the nfs share can't read


Expected results:
Working fail2ban


Additional info:
SELinux Log:
type=AVC msg=audit(1626675276.055:38476): avc:  denied  { read } for  pid=2143832 comm="fail2ban-server" name="nextcloud_data" dev="dm-4" ino=4199669 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_sys_rw_content_t:s0 tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1626675276.055:38476): arch=c000003e syscall=6 success=no exit=-13 a0=7f30781765a8 a1=7f30789bb8a0 a2=7f30789bb8a0 a3=0 items=0 ppid=1 pid=2143832 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-server" exe="/usr/libexec/platform-python3.6" subj=system_u:system_r:fail2ban_t:s0 key=(null)ARCH=x86_64 SYSCALL=lstat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=AVC msg=audit(1626675564.050:38499): avc:  denied  { read } for  pid=2149597 comm="fail2ban-server" name="nextcloud_data" dev="dm-4" ino=4199669 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_sys_rw_content_t:s0 tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1626675564.050:38499): arch=c000003e syscall=6 success=no exit=-13 a0=7f4027acd5f0 a1=7f40283138a0 a2=7f40283138a0 a3=0 items=0 ppid=1 pid=2149597 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-server" exe="/usr/libexec/platform-python3.6" subj=system_u:system_r:fail2ban_t:s0 key=(null)ARCH=x86_64 SYSCALL=lstat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
ype=AVC msg=audit(1626675276.055:38476): avc:  denied  { read } for  pid=2143832 comm="fail2ban-server" name="nextcloud_data" dev="dm-4" ino=4199669 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_sys_rw_content_t:s0 tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1626675276.055:38476): arch=c000003e syscall=6 success=no exit=-13 a0=7f30781765a8 a1=7f30789bb8a0 a2=7f30789bb8a0 a3=0 items=0 ppid=1 pid=2143832 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-server" exe="/usr/libexec/platform-python3.6" subj=system_u:system_r:fail2ban_t:s0 key=(null)ARCH=x86_64 SYSCALL=lstat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=AVC msg=audit(1626675564.050:38499): avc:  denied  { read } for  pid=2149597 comm="fail2ban-server" name="nextcloud_data" dev="dm-4" ino=4199669 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_sys_rw_content_t:s0 tclass=lnk_file permissive=0
type=SYSCALL msg=audit(1626675564.050:38499): arch=c000003e syscall=6 success=no exit=-13 a0=7f4027acd5f0 a1=7f40283138a0 a2=7f40283138a0 a3=0 items=0 ppid=1 pid=2149597 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-server" exe="/usr/libexec/platform-python3.6" subj=system_u:system_r:fail2ban_t:s0 key=(null)ARCH=x86_64 SYSCALL=lstat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=AVC msg=audit(1626676002.379:38542): avc:  denied  { search } for  pid=2150952 comm="fail2ban-server" name="mnt" dev="dm-0" ino=141 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:automount_tmp_t:s0 tclass=dir permissive=0
type=SYSCALL msg=audit(1626676002.379:38542): arch=c000003e syscall=6 success=no exit=-13 a0=7f27f42fe610 a1=7f27f4b408a0 a2=7f27f4b408a0 a3=1 items=0 ppid=1 pid=2150952 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-server" exe="/usr/libexec/platform-python3.6" subj=system_u:system_r:fail2ban_t:s0 key=(null)ARCH=x86_64 SYSCALL=lstat AUID="unset" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"

Comment 1 customercare 2021-07-22 08:36:24 UTC
Hi,

I'm not sure, if nfs transports selcontexts on files and directories by itself, but it does not look like it.

You can set a SELcontext while mounting your share to solve this:

https://www.thegeeksearch.com/how-to-configure-selinux-labeled-nfs-exports/

While you're on it.. use nfs version 4 and enable encryption for your share.

Comment 2 Frank Büttner 2021-07-22 14:52:17 UTC
The storage system only support nfs 4.1 and as I understand, your link only works with nfs 4.2 and newer.

Comment 3 Richard Shaw 2021-11-02 12:33:48 UTC
Has this been addressed or a workaround implemented? I'm not sure what I can do about this from on the packaging side.

Comment 4 customercare 2021-11-02 12:47:15 UTC
@Richard:

That's for sure nothing you can fix in fail2ban, as no fedora package is responsible for external mounts. It's an impossibility on the logical side.

Comment 5 Richard Shaw 2021-11-02 13:02:43 UTC
Thanks for the confirmation. I'm closing for now but if a solution presents itself, it can be reopened.