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]
Created attachment 849470 [details]
Created attachment 849471 [details]
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 :
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.
*** This bug has been marked as a duplicate of bug 1116450 ***