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.
Created attachment 849467 [details] sealert output for sshd avc
Created attachment 849468 [details] sealert output for sddm avc
Created attachment 849469 [details] journald output
Created attachment 849470 [details] secure log
Created attachment 849471 [details] /var/log/audit/audit.log
It looks you have labeling issue. Please run # fixfile restore to fix labeling on your system.
This is reproducible on Rawhide by many people, it's not specific to the reporter's system.
*** Bug 1053349 has been marked as a duplicate of this bug. ***
You mean mislabeled system. Maybe there are only binaries mislabeled. Do you have also this issue?
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.
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?
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.
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 [1]: 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. [1] https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_installed_system_boot_behavior
*** This bug has been marked as a duplicate of bug 1116450 ***