| Summary: | selinux is blocking password authentication by sshd | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bruno Wolff III <bruno> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | bruno, dominick.grift, dwalsh, lvrabec, mgrepl, mrmazda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-05-20 14:56:16 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: | |
|
Description
Bruno Wolff III
2013-12-19 03:44:39 UTC
I did a minimal HTTP F20 installation a few hours ago as a foundation for F21, and could not log in until booting with selinux=0 enforcing=0 on cmdline. Until then, after entering password, screen cleared to fresh login prompt each time. I since upgraded to F21, and booting with either selinux=0 or enforcing=0 is no longer required to be able to log in. What AVC's are you seeing? Did a relabel fix the problem? enforcing=0 should have been sufficient. I did a relabel (using restorecon -vr /) and restarted sshd and the problem was not fixed. The AVCs I saw were journal or setroubleshoot daemon related. I didn't see any that looked sshd or password file related. Bruno anything in /var/log/secure? I am running rawhide and have not seen the problem. ps -eZ | grep sshd ps -eZ | grep sshd
system_u:system_r:sshd_t:s0-s0:c0.c1023 17921 ? 00:00:00 sshd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 17947 ? 00:00:01 sshd
system_u:system_r:sshd_t:s0-s0:c0.c1023 31295 ? 00:00:00 sshd
I confirmed that the issue is still present this afternoon.
The failure I just got didn't generate any entries in /var/log/secure.
I am getting the following in /var/log/messages:
Dec 19 14:21:19 bruno setroubleshoot: SELinux is preventing systemd-journal from write access on the sock_file . For complete SELinux messages. run sealert -l 5b6e786e-f7cc-4403-80cb-1160cdca3749
I'm seeing the following AVCs in audit.log:
type=AVC msg=audit(1387484415.257:16162): avc: denied { write } for pid=15950 comm="rpm" name="__db.001" dev="dm-1" ino=1925409 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1387484490.267:16163): avc: denied { write } for pid=977 comm="systemd-journal" name="d983291a211058e27fe57298494fe9c0" dev="dm-1" ino=1966805 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir
type=AVC msg=audit(1387484490.267:16164): avc: denied { remove_name } for pid=977 comm="systemd-journal" name="system.journal" dev="dm-1" ino=1967002 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir
type=AVC msg=audit(1387484490.267:16165): avc: denied { rename } for pid=977 comm="systemd-journal" name="system.journal" dev="dm-1" ino=1967002 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1387484490.267:16166): avc: denied { add_name } for pid=977 comm="systemd-journal" name="system" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir
type=AVC msg=audit(1387484490.279:16167): avc: denied { create } for pid=977 comm="systemd-journal" name="system.journal" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1387484490.289:16168): avc: denied { setattr } for pid=977 comm="systemd-journal" name="system.journal" dev="dm-1" ino=1972793 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
Maybe my policy got messed up somehow. In the past I have had local policy changes break updates of policy and I need to uninstall targeted and reinstall it. If you aren't seeing the problem, that makes an update issue seem more likely.
I have some more information, but am still working through this. I tried a reboot and the boot failed. I believe there was a problem mounting some of the luks systems. I rebooted again in permissive mode, removed /etc/selinux/targeted, reinstalled selinux-policy-targeted, rebuilt my initramfs image and rebooted. The system booted in enforcing mode, but I couldn't login to either kdm or a VT. I rebooted in permissive mode and was able to login. I then switched to enforcing and confirmed that I couldn't ssh in. At this point I want to do another relabel. It seems like something was messed up with the policy data (or perhaps it was just an initramfs image built with an older policy problem). I'll report back later after I get the relabel done and see if I can get some useful log information. I finished another relabel and sshd still has the problem. (I can't test kdm and VTs yet.) I got some interesting log entries that might be helpful. I'll still want to try a reboot later to make sure the processes are all labelled correctly.
type=USER_AVC msg=audit(1387568739.249:1344): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:kernel_t:s0 msg='avc: received setenforce notice (enforcing=1) exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
type=AVC msg=audit(1387568739.282:1351): avc: denied { dyntransition } for pid=28419 comm="sshd" scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
type=AVC msg=audit(1387568739.362:1354): avc: denied { transition } for pid=28420 comm="sshd" path="/usr/bin/bash" dev="dm-0" ino=945718 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process
My policy might have initially been messed up because I have a local policy file that refers to httpd_sys_content_rw_t, which looks like it was renamed to httpd_sys_rw_content_t at some point. This could have caused some policy updates to fail, leaving things in a bad state. Hopefully when I do a reboot later things will be fully back to normal. Some things have improved, but now I am seeing a lot of exec* AVCs. For example:
type=AVC msg=audit(1387655901.407:64): avc: denied { execstack } for pid=1446 comm="upsmon" scontext=system_u:system_r:nut_upsmon_t:s0 tcontext=system_u:system_r:nut_upsmon_t:s0 tclass=process
type=AVC msg=audit(1387655901.407:64): avc: denied { execmem } for pid=1446 comm="upsmon" scontext=system_u:system_r:nut_upsmon_t:s0 tcontext=system_u:system_r:nut_upsmon_t:s0 tclass=process
type=AVC msg=audit(1387655901.409:65): avc: denied { execmod } for pid=1446 comm="upsmon" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:nut_upsmon_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655905.852:66): avc: denied { execmod } for pid=1498 comm="setroubleshootd" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655909.409:68): avc: denied { execstack } for pid=1342 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process
type=AVC msg=audit(1387655909.409:68): avc: denied { execmem } for pid=1342 comm="httpd" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process
type=AVC msg=audit(1387655909.414:69): avc: denied { execmod } for pid=1342 comm="httpd" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655916.795:70): avc: denied { execmem } for pid=1337 comm="asterisk" scontext=system_u:system_r:asterisk_t:s0 tcontext=system_u:system_r:asterisk_t:s0 tclass=process
type=AVC msg=audit(1387655919.420:71): avc: denied { execmod } for pid=1596 comm="krootimage" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655936.293:77): avc: denied { execstack } for pid=1792 comm="polkitd" scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:system_r:policykit_t:s0 tclass=process
type=AVC msg=audit(1387655936.294:78): avc: denied { execmod } for pid=1792 comm="polkitd" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655939.057:85): avc: denied { execstack } for pid=1900 comm="sendmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=process
type=AVC msg=audit(1387655939.057:85): avc: denied { execmem } for pid=1900 comm="sendmail" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=process
type=AVC msg=audit(1387655939.063:86): avc: denied { execmod } for pid=1900 comm="sendmail" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655964.818:95): avc: denied { execstack } for pid=2244 comm="tumblerd" scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1387655965.962:96): avc: denied { execmod } for pid=2285 comm="setroubleshootd" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387655969.315:97): avc: denied { execstack } for pid=2311 comm="pkla-check-auth" scontext=system_u:system_r:policykit_auth_t:s0 tcontext=system_u:system_r:policykit_auth_t:s0 tclass=process
type=AVC msg=audit(1387655969.317:98): avc: denied { execmod } for pid=2311 comm="pkla-check-auth" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:policykit_auth_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387656024.839:128): avc: denied { execstack } for pid=2604 comm="sendmail" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1387656024.839:128): avc: denied { execmem } for pid=2604 comm="sendmail" scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1387656024.861:129): avc: denied { execmod } for pid=2604 comm="sendmail" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file
type=AVC msg=audit(1387656025.319:132): avc: denied { execmod } for pid=2606 comm="setroubleshootd" path="/usr/lib/libk5crypto.so.3.1" dev="dm-1" ino=932433 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file
I am not sure if I broke something while trying to fix things, or if this came in with an update while I was worrying about the login issue. Testing the login issue is a problem now, as the exec* AVCs kick in first.
This has been fixed for a while now. Sorry I forgot to go back and close thisbug in a timely manner. |