|Summary:||selinux-policy preventing login through sddm and ssh|
|Product:||[Fedora] Fedora||Reporter:||Dan Mossor [danofsatx] <danofsatx>|
|Component:||selinux-policy-targeted||Assignee:||Miroslav Grepl <mgrepl>|
|Status:||CLOSED DUPLICATE||QA Contact:||Ben Levenson <benl>|
|Version:||rawhide||CC:||danofsatx, dwalsh, hakan_duran, kevin, mattdm, mbriza, nonamedotc, robatino, tflink|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-07-11 08:06:38 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Dan Mossor [danofsatx] 2014-01-13 15:57:59 UTC
selinux-policy-3.13.1-12.fc21.noarch.rpm is preventing transition and dyntransition access to login methods. System has not been relabled, only change was update to the above policy. [root@g55]# ls -lZ /usr/sbin/sshd -rwxr--xr-x. root root unconfined_u:object_r:bin_t:s0 /usr/sbin/sshd [root@g55]# ls -lZ /bin/sddm -rwxr--xr-x. root root system_u:object_r:bin_t:s0 /bin/sddm Attached are the sealert outputs for the AVC denials. This is a major issue - only login permitted (on KDE systems) is console login - logging in with sddm or ssh is not possible. From my untrained eye, it appears that access to PAM is being denied, so authentication cannot proceed - but that doesn't make sense in my head since console login works. Workaround is to issue 'setenforce 0' in the alt-F2 console, and then restart sddm service.
Comment 1 Dan Mossor [danofsatx] 2014-01-13 15:58:53 UTC
Created attachment 849467 [details] sealert output for sshd avc
Comment 2 Dan Mossor [danofsatx] 2014-01-13 15:59:30 UTC
Created attachment 849468 [details] sealert output for sddm avc
Comment 3 Dan Mossor [danofsatx] 2014-01-13 16:00:13 UTC
Created attachment 849469 [details] journald output
Comment 4 Dan Mossor [danofsatx] 2014-01-13 16:01:21 UTC
Created attachment 849470 [details] secure log
Comment 5 Dan Mossor [danofsatx] 2014-01-13 16:02:12 UTC
Created attachment 849471 [details] /var/log/audit/audit.log
Comment 6 Miroslav Grepl 2014-01-13 16:18:26 UTC
It looks you have labeling issue. Please run # fixfile restore to fix labeling on your system.
Comment 7 Kevin Kofler 2014-01-15 17:51:43 UTC
This is reproducible on Rawhide by many people, it's not specific to the reporter's system.
Comment 8 Kevin Kofler 2014-01-15 17:52:16 UTC
*** Bug 1053349 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Grepl 2014-01-16 13:09:28 UTC
You mean mislabeled system. Maybe there are only binaries mislabeled. Do you have also this issue?
Comment 10 Kevin Kofler 2014-01-16 23:10:13 UTC
I don't use Rawhide (which seems the only Fedora release affected), nor do I have SELinux enabled, so I have not encountered this personally. But several people have been complaining about this issue on #fedora-kde on IRC. It doesn't seem specific to any particular system. If the labeling is getting messed up, that's happening systematically with the selinux-policy update.
Comment 11 Daniel Walsh 2014-01-23 17:35:23 UTC
I guess the question is what tools are they using to get updated to Rawhide. rpm should have put the label of sshd_exec_t on the /usr/sbin/sshd, why it did not get labeled that way we don't know and it has nothing to do with selinux-policy. Might be fedup?
Comment 12 Tim Flink 2014-07-09 18:19:29 UTC
Discussed at the 2014-07-09 Fedora 21 alpha blocker review meeting. It's not clear to us whether or not this affects fresh installs, which would be required in order to be accepted as a release blocking bug for F21 alpha. Please re-test against a fresh install or update with additional information.
Comment 13 Tim Flink 2014-07-09 18:22:07 UTC
Apologies for the noise, I submitted that last comment a little too quickly. Discussed at the 2014-07-09 Fedora 21 alpha blocker review meeting. Accepted as a blocker for Fedora 21 alpha due to violation of the following alpha release criteria : A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.  https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_installed_system_boot_behavior