Bug 1052317 - selinux-policy preventing login through sddm and ssh
Summary: selinux-policy preventing login through sddm and ssh
Keywords:
Status: CLOSED DUPLICATE of bug 1116450
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard: AcceptedBlocker
: 1053349 (view as bug list)
Depends On:
Blocks: F21AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2014-01-13 15:57 UTC by Dan Mossor [danofsatx]
Modified: 2014-07-11 08:06 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-11 08:06:38 UTC


Attachments (Terms of Use)
sealert output for sshd avc (2.06 KB, text/plain)
2014-01-13 15:58 UTC, Dan Mossor [danofsatx]
no flags Details
sealert output for sddm avc (2.14 KB, text/plain)
2014-01-13 15:59 UTC, Dan Mossor [danofsatx]
no flags Details
journald output (81.61 KB, text/plain)
2014-01-13 16:00 UTC, Dan Mossor [danofsatx]
no flags Details
secure log (2.08 KB, text/plain)
2014-01-13 16:01 UTC, Dan Mossor [danofsatx]
no flags Details
/var/log/audit/audit.log (14.55 KB, text/plain)
2014-01-13 16:02 UTC, Dan Mossor [danofsatx]
no flags Details

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


Note You need to log in before you can comment on or make changes to this bug.