Created attachment 1713250 [details] sealert -l 73a7960e-f1fa-4272-9a4c-2ca689296b26 Description of problem: I am using automounted nfs-homedirs. The upgrade to kernel-5.8.x broke my working setup, seemingly with SELinux related causes. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.14.5-42.fc32.noarch selinux-policy-3.14.5-42.fc32.noarch or selinux-policy-3.14.5-43.fc32.noarch selinux-policy-targeted-3.14.5-43.fc32.noarch and kernel-5.8.4-200.fc32.x86_64 How reproducible: Always. Steps to Reproduce: Attempt to ssh from machine "machine1" into machine "machine2", with "machine2" running kernel-5.8.4-200.fc32.x86_64: $ ssh machine2 user@machine2's password: Last login: Tue Sep 1 06:41:02 2020 from ... Could not chdir to home directory /users/user: No such file or directory From machine1's log: ... Sep 01 06:40:59 machine2 setroubleshoot[1530]: SELinux is preventing sshd from write access on the fifo_file fifo_file. For complete SELinux messages run: sealert -l 73a7960e-f1fa-4272-9a4c-2ca689296b26 When reverting machine2 back to kernel-5.7.17-200.fc32.x86_64 or switching off SElinux, these issues immediate vanish. Expected results: Function. Additional info: I am not sure, if this apparent regression is caused by SELinux or if SELinux is just the messenger about a bug/incompatibility elsewhere (kernel?) ;)
Ralf, Could you look for avc denials? # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today Is there any additional information logged?
Created attachment 1713254 [details] journalctl -r
(In reply to Zdenek Pytela from comment #1) > Ralf, > > Could you look for avc denials? > > # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today This is what ausearch reports: type=USER_AVC msg=audit(09/01/2020 09:02:40.683:121) : pid=805 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=AVC msg=audit(09/01/2020 09:03:19.892:195) : avc: denied { write } for pid=1255 comm=sshd path=pipe:[32732] dev="pipefs" ino=32732 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:automount_t:s0 tclass=fifo_file permissive=0 > Is there any additional information logged? Cf. the journalctl-attachment above. BTW: Why did you change the severity of this BZ? I guess, you are underestimating the impact this bug has: To put it bluntly: The upgrade to kernel-5.8.x kills my network! I guess, I don't have to be more explicit.
I see just this denial: Sep 01 09:03:19 machine2 audit[1255]: AVC avc: denied { write } for pid=1255 comm="sshd" path="pipe:[32732]" dev="pipefs" ino=32732 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:automount_t:s0 tclass=fifo_file permissive=0 It would help if you were able to switch the system to permissive and gather all denials: # setenforce 0 <reproduce> # setenforce 1 # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent The recent modifier means last 10 minutes. In the kernel changelog I cannot see anything directly related, I'd like to ensure it was just kernel and no other component update that triggers this issue. For the severity I am sorry, I haven't noticed it been set already.
---- type=USER_AVC msg=audit(09/01/2020 10:10:17.727:117) : pid=800 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=AVC msg=audit(09/01/2020 10:10:56.367:193) : avc: denied { write } for pid=1248 comm=sshd path=pipe:[33561] dev="pipefs" ino=33561 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:automount_t:s0 tclass=fifo_file permissive=1 (In reply to Zdenek Pytela from comment #4) > I see just this denial: > > Sep 01 09:03:19 machine2 audit[1255]: AVC avc: denied { write } for > pid=1255 comm="sshd" path="pipe:[32732]" dev="pipefs" ino=32732 > scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=system_u:system_r:automount_t:s0 tclass=fifo_file permissive=0 Setting SELINUX=permissive in /etc/selinux/config, this changes into: type=AVC msg=audit(09/01/2020 10:10:56.367:193) : avc: denied { write } for pid=1248 comm=sshd path=pipe:[33561] dev="pipefs" ino=33561 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:automount_t:s0 tclass=fifo_file permissive=1 It also lets ssh-ing into this machine succeed. The automounted homedir (/users/user1) is mounted. > It would help if you were able to switch the system to permissive and gather > all denials: With both enforcing/permissive I only see these 2 sealerts listed above. The only difference is the value of "permissive" changing from 0 to 1. NB: With SELINUX=enforcing the ssh-login actually succeeds. It's just that the user's nfs-/autofs-mounted home directory is missing. > In the kernel changelog I cannot see anything directly related, I'd like to > ensure it was just kernel and no other component update that triggers this > issue. I wish, I knew what the cause is ;)
The following rule, loaded as a module, solves the problem. Please, would you update the policy? # grep automount /var/log/audit/audit.log | audit2allow -m sshd-automount module sshd-automount 1.0; require { type sshd_t; type automount_t; class fifo_file write; } #============= sshd_t ============== allow sshd_t automount_t:fifo_file write;
The same problem exists to dovecot, and possible any service that will initiate the first access to automounted home directory (and possible other automount directories). All get an access denied for automount_t:fifo_file write, resulting in an still not mounted autofs partition. module dovecot-automount 1.0; require { type dovecot_t; type automount_t; class fifo_file write; } #============= dovecot_t ============== allow dovecot_t automount_t:fifo_file write;
The same problem exists to sendmail. I think there should be general (?) allow rule for "automount_t:fifo_file write;", because it seems to be necessary to access a currently umounted autofs partition since some of the last kernels (5.8.x?). module sendmail_automount 1.0; require { type automount_t; type sendmail_t; class fifo_file write; } #============= sendmail_t ============== allow sendmail_t automount_t:fifo_file write;
Hi, Having had a look around I still think this is likely an selinux policy problem. What happens is that autofs, running as the root user, will open a pipe for kernel communication. autofs then listens for kernel messages on the read end. The kernel will write to the pipe "in the context of the process triggering an automount" which can be any system process, not the context of the pipe creator. But now there's now an additional check since the kernel write function has recently changed (kernel function security_file_permission()) and that permission check should pass not fail in this case. Is it sensible to update the selinux policy based on this?
(In reply to Ian Kent from comment #9) > Is it sensible to update the selinux policy based on this? Well, we can add the rule temporarily for now (with a comment to revisit it once the kernel solution is settled on), but as I replied in the kernel ML thread [1], I don't the LSM check is logical in this particular case. [1] https://lore.kernel.org/selinux/CAFqZXNsoXr1eA4C8==Nvujs5ONpRnuSqaOQQ0n78R=Dbm-EFGA@mail.gmail.com/T/#m9f937be6c59ef852fc27d9c540dfa3da9496502d
(In reply to Ondrej Mosnacek from comment #10) > (In reply to Ian Kent from comment #9) > > Is it sensible to update the selinux policy based on this? > > Well, we can add the rule temporarily for now (with a comment to revisit it > once the kernel solution is settled on), but as I replied in the kernel ML > thread [1], I don't the LSM check is logical in this particular case. > > [1] > https://lore.kernel.org/selinux/ > CAFqZXNsoXr1eA4C8==Nvujs5ONpRnuSqaOQQ0n78R=Dbm-EFGA.com/T/ > #m9f937be6c59ef852fc27d9c540dfa3da9496502d Yes, I see your comment, thanks for working on this, your input has been quite useful. As I said upstream I'm inclined to disagree but Stephen Smalley has yet another recommendation so we'll need to wait and see what results from the discussion.
*** Bug 1875801 has been marked as a duplicate of this bug. ***
For all readers information: This bz really seems to be a result of a recent change in kernel. There is an ongoing discussion in the kernel mailing list how to deal with this issue. Ian: I tend to wait for a conclusion, unless there was a demand for a quick solution/workaround.
(In reply to Zdenek Pytela from comment #13) > For all readers information: > This bz really seems to be a result of a recent change in kernel. > There is an ongoing discussion in the kernel mailing list how to deal with > this issue. > > Ian: > I tend to wait for a conclusion, unless there was a demand for a quick > solution/workaround. The workaround is to create a standalone policy module for AVCs that are a problem. That was shown here but I posted slightly more detailed instructions in the duplicate bug 1875801.
That workaround is a bit of a whack-a-mole though as any context can trigger this bug. So it looks like putting SELinux in permissive mode is the only reliable workaround for now. :/
It is possible to add a single rule to cover all domains: ``` module local_autofs 1.0; require { attribute domain; type automount_t; class fifo_file write; } allow domain automount_t:fifo_file write; ```
After internal discussion, we are going to address the issue in the policy: https://github.com/fedora-selinux/selinux-policy/pull/444
Kernel 5.8 has made it to F31, so it would be greatly appreciated if this fix made it there as well.
Refer to https://github.com/fedora-selinux/selinux-policy/pull/447 https://github.com/fedora-selinux/selinux-policy/pull/448 https://github.com/fedora-selinux/selinux-policy/pull/449 for backports to F31-F33.
FEDORA-2020-9896f80cf0 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9896f80cf0
FEDORA-2020-9896f80cf0 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9896f80cf0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9896f80cf0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-9896f80cf0 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
Fyi, Linus has committed a fix for this problem upstream, it will be included in kernel 5.9. If we want to we can revert this after we update the Fedora kernel to 5.9.
(In reply to Ian Kent from comment #23) > Fyi, > > Linus has committed a fix for this problem upstream, it will be > included in kernel 5.9. > > If we want to we can revert this after we update the Fedora kernel > to 5.9. And it appears Greg Kroah-Hartman is in the process of committing the fix to stable 5.8 too.
Ian, Thank you for the information, I was only a part of the initial Ondrej's thread. The likely scenario is we will revert it in rawhide as soon as the new kernel is there and with reasonable delay in other Fedora releases.
Hello, Is there a fix for CentOS 7 systems ? Looks like issue still exists in "5.10.4-1.el7.elrepo.x86_64"
I mean to say issue still exists with "selinux-policy-3.13.1-268.el7_9.2.noarch" and "5.10.4-1.el7.elrepo.x86_64" for CentOS 7 Systems.