Bug 1046112 - SELinux execmem/execstack denials preventing sssd working in Rawhide
SELinux execmem/execstack denials preventing sssd working in Rawhide
Status: CLOSED DUPLICATE of bug 1045699
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
Depends On:
Blocks: F21AlphaBlocker
  Show dependency treegraph
Reported: 2013-12-23 12:44 EST by Adam Williamson
Modified: 2014-01-02 16:29 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-02 16:29:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
'journalctl -b | grep sssd' output on affected system, showing the denials (36.33 KB, text/plain)
2013-12-23 12:49 EST, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2013-12-23 12:44:53 EST
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 12:49:40 EST
Created attachment 840914 [details]
'journalctl -b | grep sssd' output on affected system, showing the denials
Comment 2 Adam Williamson 2013-12-23 12:56:16 EST
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-23 22:31:17 EST
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 14:15:48 EST
Just looked into this some and filed: 


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 08:34:33 EST
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 16:29:04 EST

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

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