Description of problem: ssh is not allowed to access /lib64/ld-linux-x86-64.so.2, yet the target is a link pointing to /usr/lib64/ld-2.28.so Version-Release number of selected component (if applicable): glibc-2.28-127.el8.x86_64 libselinux-2.9-4.el8_3.x86_64 libselinux-utils-2.9-4.el8_3.x86_64 python3-libselinux-2.9-4.el8_3.x86_64 rpm-plugin-selinux-4.14.3-4.el8.x86_64 selinux-policy-3.14.3-54.el8.noarch selinux-policy-targeted-3.14.3-54.el8.noarch How reproducible: Always (tested on 5 VMs) Steps to Reproduce: 1.Update a 8.1 minimal install to 8.3 Actual results: ssh is not allowed to access /usr/lib64/ld-linux-x86-64.so.2 due to the selinux context 'lib_t' , while the target has a mismatching context of 'ld_so_t' -rwxr-xr-x. 1 root root system_u:object_r:ld_so_t:s0 252280 Jul 20 18:56 /usr/lib64/ld-2.28.so lrwxrwxrwx. 1 root root system_u:object_r:lib_t:s0 10 Jul 20 18:45 /usr/lib64/ld-linux-x86-64.so.2 -> ld-2.28.so Expected results: Both Link and target should have the same selinux context Additional info: sealert -a /var/log/audit/audit.log (truncated output): SELinux is preventing /usr/bin/ssh from execute access on the file /lib64/ld-linux-x86-64.so.2. ***** Plugin restorecon (92.2 confidence) suggests ************************ If you want to fix the label. /lib64/ld-linux-x86-64.so.2 default label should be ld_so_t. Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly. Do # /sbin/restorecon -v /lib64/ld-linux-x86-64.so.2 ***** Plugin catchall_boolean (7.83 confidence) suggests ****************** If you want to allow rsync to client Then you must tell SELinux about this by enabling the 'rsync_client' boolean. Do setsebool -P rsync_client 1 ***** Plugin catchall (1.41 confidence) suggests ************************** If you believe that ssh should be allowed execute access on the ld-linux-x86-64.so.2 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'ssh' --raw | audit2allow -M my-ssh # semodule -X 300 -i my-ssh.pp Additional Information: Source Context system_u:system_r:rsync_t:s0 Target Context system_u:object_r:ssh_exec_t:s0 Target Objects /lib64/ld-linux-x86-64.so.2 [ file ] Source ssh Source Path /usr/bin/ssh Port <Unknown> Host <Unknown> Source RPM Packages openssh-clients-8.0p1-5.el8.x86_64 Target RPM Packages glibc-2.28-127.el8.x86_64 SELinux Policy RPM selinux-policy-targeted-3.14.3-54.el8.noarch Local Policy RPM selinux-policy-targeted-3.14.3-54.el8.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name glustera.localdomain Platform Linux glustera.localdomain 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020 x86_64 x86_64 Alert Count 2 First Seen 2020-12-27 20:02:27 EET Last Seen 2020-12-27 20:22:37 EET Local ID 8dd00f53-2593-4a64-8abb-232165849cfc Raw Audit Messages type=AVC msg=audit(1609093357.784:2069): avc: denied { execute } for pid=15863 comm="rsync" name="ssh" dev="dm-0" ino=58937640 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1609093357.784:2069): avc: denied { read open } for pid=15863 comm="rsync" path="/usr/bin/ssh" dev="dm-0" ino=58937640 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1609093357.784:2069): avc: denied { execute_no_trans } for pid=15863 comm="rsync" path="/usr/bin/ssh" dev="dm-0" ino=58937640 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1609093357.784:2069): avc: denied { map } for pid=15863 comm="ssh" path="/usr/bin/ssh" dev="dm-0" ino=58937640 scontext=system_u:system_r:rsync_t:s0 tcontext=system_u:object_r:ssh_exec_t:s0 tclass=file permissive=1 type=SYSCALL msg=audit(1609093357.784:2069): arch=x86_64 syscall=execve success=yes exit=0 a0=7ffd275c6400 a1=7ffd275c65f0 a2=7ffd275c96e0 a3=7ffd275caf00 items=1 ppid=15862 pid=15863 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=ssh exe=/usr/bin/ssh subj=system_u:system_r:rsync_t:s0 key=(null)^]ARCH=x86_64 SYSCALL=execve AUID=unset UID=root GID=root EUID=root SUID=root FSUID=root EGID=root SGID=root FSGID=root type=CWD msg=audit(1609093357.784:2069): cwd=/tmp/gsyncd-aux-mount-piuvfhyq type=PATH msg=audit(1609093357.784:2069): item=0 name=/lib64/ld-linux-x86-64.so.2 inode=29360488 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0^]OUID=root OGID=root Hash: ssh,rsync_t,ssh_exec_t,file,execute -------------------------------------------------------------------------------- [root@glustera ~]# semanage fcontext -a -t 'ld_so_t' /usr/lib64/ld-linux-x86-64.so.2 ValueError: File spec /usr/lib64/ld-linux-x86-64.so.2 conflicts with equivalency rule '/usr/lib64 /usr/lib'; Try adding '/usr/lib/ld-linux-x86-64.so.2' instead [root@glustera ~]# semanage fcontext -l | less [root@glustera ~]# semanage fcontext -l | grep lib64 /lib64 all files system_u:object_r:lib_t:s0 /usr/lib64/nagios/plugins/check_node_accept_status regular file system_u:object_r:nagios_openshift_plugin_exec_t:s0 /usr/lib64/nagios/plugins/check_number_openshift_apps regular file system_u:object_r:nagios_openshift_plugin_exec_t:s0 /usr/lib64/security/pam_krb5/pam_krb5_cchelper regular file system_u:object_r:bin_t:s0 /var/spool/postfix/lib64(/.*)? all files system_u:object_r:lib_t:s0 /lib64 = /usr/lib /usr/lib64 = /usr/lib /usr/local/lib64 = /usr/lib /var/named/chroot/usr/lib64 = /usr/lib /var/named/chroot/lib64 = /usr/lib
Using the following fixes the selinux type: ``` # semanage fcontext -a -t 'ld_so_t' "/usr/lib/ld-linux-x86-64.so.2" # restorecon -RFvv /usr/lib64/ld-linux-x86-64.so.2 Relabeled /usr/lib64/ld-linux-x86-64.so.2 from system_u:object_r:lib_t:s0 to system_u:object_r:ld_so_t:s0 ```
Hi, Could you please remove all customizations, follow rather the recommendation of the catchall_boolean plugin: ===== ***** Plugin catchall_boolean (7.83 confidence) suggests ****************** If you want to allow rsync to client Then you must tell SELinux about this by enabling the 'rsync_client' boolean. Do setsebool -P rsync_client 1 ===== i. e. run # setsebool -P rsync_client 1 and try again? Note the -P switch makes the change permanent; without it, it will remain valid until boot.
I've rebuild the setup and setting the boolean 'rsync_client' to '1' prevents that denial. I guess it can be added as part of the official documentation. Yet, as I'm using upstream gluster (v8.3) , most probably it should go to the upstream documentation unless the code for 8.3 is merged with RHGS 3.5
As there seems to bo no issue with selinux-policy, I am switching the product & component to assess if any additional action is needed.
Hi Strahil, Can you please elaborate on what is to be documented. I think a better place to request for updating the documentation would be to open the github issue at : https://github.com/gluster/glusterdocs/issues Thanks for reporting the problem. I would close this bug from here, as it needs to be opened at the above location.
I also am seeing a stupid array of similar garbage in my logs after updating to 8.3 SELinux is preventing /usr/libexec/platform-python3.6 from getattr access on the file /usr/sbin/kpatch SELinux is preventing rhsmcertd-worke from open access on the file /etc/dnf/modules.d/container-tools.module. SELinux is preventing rhsmcertd-worke from node_bind access on the tcp_socket port None Also seeing this garbage, although that's a completely different issue: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out It's just pathetic. No-one should have to deal with this garbage fire of an OS.
I believe that: * the first "SELinux is preventing ..." problem is reported as https://bugzilla.redhat.com/show_bug.cgi?id=1895322 * the second "SELinux is preventing ..." problem means that /etc/dnf/modules.d/container-tools.module file is mislabeled and "restorecon -Rv /etc/dnf" command should fix it * the third "SELinux is preventing ..." problem is reported as https://bugzilla.redhat.com/show_bug.cgi?id=1923985