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.
Created attachment 840914 [details] 'journalctl -b | grep sssd' output on affected system, showing the denials
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.
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.)
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.
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.
*** This bug has been marked as a duplicate of bug 1045699 ***