Bug 1046112

Summary: SELinux execmem/execstack denials preventing sssd working in Rawhide
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: sssdAssignee: Jakub Hrozek <jhrozek>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: abokovoy, bruno, dwalsh, jhrozek, kevin, lslebodn, mgrepl, pbrezina, robatino, sbose, sgallagh, ssorce
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-01-02 21:29:04 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
'journalctl -b | grep sssd' output on affected system, showing the denials none

Description Adam Williamson 2013-12-23 17:44:53 UTC 
Currently if I boot my Rawhide box with SELinux enabled and enforcing, I can never log in with FreeIPA credentials, as sssd fails due to multiple SELinux denials for execmem and execstack.

If I boot with enforcing=0, I can log in successfully.

Attaching journalctl output indicating the denials. There are multiple execmem/execstack denials causing issues in Rawhide currently, I'm not sure if we're expected to file these on SELinux or the offending components - CCIng SELinux folks.
Comment 1 Adam Williamson 2013-12-23 17:49:40 UTC 
Created attachment 840914 [details]
'journalctl -b | grep sssd' output on affected system, showing the denials
Comment 2 Adam Williamson 2013-12-23 17:56:16 UTC 
I actually have a huge pile of execmem/execstack denials when booting Rawhide; there's this one and dhclient (that's bug #1045682), sure, but I also see firewalld, sshd, nfsd, postfix, certmonger, rpcbind, cupsd...

either there's a bug in SELinux or it's introduced some new policy that just about *everything* violates, I think.
Comment 3 Bruno Wolff III 2013-12-24 03:31:17 UTC 
I have been seeing this to. I originally had a problem that was less severe due to policy updates being blocked due to a local policy that referred to something that was renamed. After taking some drastic action to fix this, I started seeing the execmod and execstack problems. However I wasn't sure if this was because I recovered things incorrectly or because there was a real problem that had been masked.

Most the the errors seem to be related to using the libk5crypto library, though I have see some other things as well. That library gets used by lots of important stuff and it's pretty hard to do much without it. Currently I do seem to be able to login to a VT when I forget to add enforcing=0 to the boot command. That lets me change to permissive after booting. (Though some services then need to be restarted.)
Comment 4 Kevin Fenzi 2013-12-24 19:15:48 UTC 
Just looked into this some and filed: 

https://bugzilla.redhat.com/show_bug.cgi?id=1046349

It looks like a libselinux/selinux-policy issue. I don't know however if it's just spewing false positives or if there is some new checking that requires these packages to be fixed.
Comment 5 Jakub Hrozek 2014-01-02 13:34:33 UTC 
We haven't changed anything that could trigger this error in SSSD. I've CCed myself to #1046349 as I suspect SELinux is ultimately the component that would need fixing.
Comment 6 Daniel Walsh 2014-01-02 21:29:04 UTC 

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