Bug 1046112 - SELinux execmem/execstack denials preventing sssd working in Rawhide
Summary: SELinux execmem/execstack denials preventing sssd working in Rawhide
Keywords:
Status: CLOSED DUPLICATE of bug 1045699
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F21AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-12-23 17:44 UTC by Adam Williamson
Modified: 2014-01-02 21:29 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-02 21:29:04 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1045682 0 high CLOSED SELinux preventing dhclient from reading libk5crypto.so.3 resulting in no addresses received/assigned 2021-02-22 00:41:40 UTC

Internal Links: 1045682

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


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