Bug 1052317

Summary: selinux-policy preventing login through sddm and ssh
Product: [Fedora] Fedora Reporter: Dan Mossor [danofsatx] <danofsatx>
Component: selinux-policy-targetedAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: danofsatx, dwalsh, hakan_duran, kevin, mattdm, mbriza, nonamedotc, robatino, tflink
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-11 08:06:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1043119    
Attachments:
Description Flags
sealert output for sshd avc
none
sealert output for sddm avc
none
journald output
none
secure log
none
/var/log/audit/audit.log none

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 [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

Comment 14 Miroslav Grepl 2014-07-11 08:06:38 UTC

*** This bug has been marked as a duplicate of bug 1116450 ***