Bug 1383018
| Summary: | selinux preventing saslauthd from using PAM and sssd | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Brian J. Murrell <brian> |
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
| Status: | CLOSED WORKSFORME | QA Contact: | sssd-qe <sssd-qe> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | brian, grajaiya, jhrozek, lslebodn, lvrabec, mgrepl, mkosek, mmalik, mzidek, pbrezina, plautrba, pvrabec, ssekidde, stephan, tscherf |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-30 14:18:18 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: | 1393066 | ||
It's interesting that generating a policy for these AVCs results in: #!!!! This avc can be allowed using the boolean 'saslauthd_read_shadow' But that's not quite what saslauthd is trying to do here but rather it's trying to use the PAM/sssd module. Could you run following commands on your machine and attach their outputs: # ls -l /var/lib/sss/pipes/ total 0 srw-rw-rw-. 1 root root 0 Oct 10 12:21 nss srw-rw-rw-. 1 root root 0 Oct 10 12:21 pam drwxr-x---. 2 sssd root 35 Oct 10 12:21 private # ls -l /var/lib/sss/pipes/private/ total 0 srw-------. 1 root root 0 Oct 10 12:21 pam srw-------. 1 root root 0 Oct 10 12:21 sbus-monitor # # ls -l /var/lib/sss/pipes/ total 4 srw-rw-rw-. 1 root root 0 Sep 26 14:05 nss srw-rw-rw-. 1 root root 0 Sep 26 14:05 pac srw-rw-rw-. 1 root root 0 Sep 26 14:05 pam drwx------. 2 sssd sssd 4096 Sep 26 14:05 private srw-rw-rw-. 1 root root 0 Sep 26 14:05 ssh srw-rw-rw-. 1 root root 0 Sep 26 14:05 sudo # ls -l /var/lib/sss/pipes/private/ total 0 srw-------. 1 root root 0 Sep 26 14:05 pam lrwxrwxrwx. 1 root root 54 Sep 26 14:05 sbus-dp_interlinx.bc.ca -> /var/lib/sss/pipes/private/sbus-dp_interlinx.bc.ca.829 srw-------. 1 root root 0 May 21 11:16 sbus-dp_interlinx.bc.ca.1220 srw-------. 1 root root 0 Aug 8 2015 sbus-dp_interlinx.bc.ca.17612 srw-------. 1 root root 0 Jan 3 2016 sbus-dp_interlinx.bc.ca.26897 srw-------. 1 root root 0 Sep 17 2015 sbus-dp_interlinx.bc.ca.2848 srw-------. 1 root root 0 Aug 3 17:47 sbus-dp_interlinx.bc.ca.29280 srw-------. 1 root root 0 Sep 17 2015 sbus-dp_interlinx.bc.ca.3262 srw-------. 1 root root 0 Sep 17 2015 sbus-dp_interlinx.bc.ca.4154 srw-------. 1 root root 0 Dec 27 2015 sbus-dp_interlinx.bc.ca.657 srw-------. 1 root root 0 Nov 24 2015 sbus-dp_interlinx.bc.ca.690 srw-------. 1 root root 0 Sep 17 2015 sbus-dp_interlinx.bc.ca.719 srw-------. 1 root root 0 Aug 13 09:57 sbus-dp_interlinx.bc.ca.809 srw-------. 1 root root 0 Jul 1 14:46 sbus-dp_interlinx.bc.ca.810 srw-------. 1 root root 0 Sep 10 20:05 sbus-dp_interlinx.bc.ca.822 srw-------. 1 root root 0 Sep 26 14:05 sbus-dp_interlinx.bc.ca.829 srw-------. 1 root root 0 Sep 17 10:30 sbus-dp_interlinx.bc.ca.845 srw-------. 1 root root 0 Jul 3 10:39 sbus-dp_interlinx.bc.ca.861 srw-------. 1 root root 0 Sep 26 14:05 sbus-monitor The one discrepancy there is /var/lib/sss/pipes/private which is "drwxr-x---. 2 sssd root" on your system and "drwx------. 2 sssd sssd" on mine. With that difference your system would not need a dac_override for root but mine would. But mine is set to the permissions/ownership that the package it comes from dictates: # rpm -qvlf /var/lib/sss/pipes/private | grep private drwx------ 2 sssd sssd 0 Aug 2 12:58 /var/lib/sss/pipes/private Which version of sssd do you use? Because it should be fixed since sssd-common-1.14.0-35. BZ1362716 If you use newer version of sssd please provide output of following commands: rpm -q sssd-common rpm -V sssd-common (In reply to Lukas Slebodnik from comment #8) > Which version of sssd do you use? # rpm -q sssd sssd-1.14.0-43.el7_3.18.x86_64 But this is now of course. When I filed the bug, back on 2016-10-09 I could most certainly, and probably have been running an older version. So let's look at the history... Sat Jul 1 2017: Updated sssd-1.14.0-43.el7_3.14.x86_64 Update 1.14.0-43.el7_3.18.x86_64 Mon May 1 2017: Updated sssd-1.14.0-43.el7_3.11.x86_64 Update 1.14.0-43.el7_3.14.x86_64 Mon Jan 23 2017: Updated sssd-1.14.0-43.el7_3.4.x86_64 Update 1.14.0-43.el7_3.11.x86_64 Fri Dec 16 2016: Updated sssd-1.13.0-40.el7_2.9.x86_64 Update 1.13.0-40.el7_2.12.x86_64 Fri Jun 24 2016: Updated sssd-1.13.0-40.el7_2.4.x86_64 Update 1.13.0-40.el7_2.9.x86_64 > Because it should be fixed since > sssd-common-1.14.0-35. BZ1362716 So I was definitely running a version older than the apparently fixed one. I'll remove my local policy module and see if this reproduces. Hmm it is interesting. Comment4 says: > Brian J. Murrell 2016-10-11 09:15:45 EDT > # ls -l /var/lib/sss/pipes/ > total 4 > srw-rw-rw-. 1 root root 0 Sep 26 14:05 nss > srw-rw-rw-. 1 root root 0 Sep 26 14:05 pac > srw-rw-rw-. 1 root root 0 Sep 26 14:05 pam > drwx------. 2 sssd sssd 4096 Sep 26 14:05 private ^^^^ and based on comment9: sssd-1.13.0-40.el7_2.9.x86_64 was used at that time. But group owner of /var/lib/sss/pipes/private should be different (root and not sssd). BTW you didn't provide output of command "rpm -V sssd-common" and it would be good to to see it together with seeing owner of directory /var/lib/sss/pipes/private ls -ld /var/lib/sss/pipes/private rpm -V sssd-common (In reply to Lukas Slebodnik from comment #10) > But group owner of /var/lib/sss/pipes/private should be different (root and > not sssd). This is the current state: # ls -l /var/lib/sss/pipes/ total 4 srw-rw-rw-. 1 root root 0 Aug 12 07:05 nss srw-rw-rw-. 1 root root 0 Aug 12 07:05 pac srw-rw-rw-. 1 root root 0 Aug 12 07:05 pam drwxr-x---. 2 sssd root 4096 Aug 12 07:05 private srw-rw-rw-. 1 root root 0 Aug 12 07:05 ssh srw-rw-rw-. 1 root root 0 Aug 12 07:05 sudo So some "latent" change? Maybe the change to root was only effected by a reboot (which really should not have been necessary). > BTW you didn't provide output of command "rpm -V sssd-common" Oh, sorry. I misread the condition on which you were looking for that. > and it would be good to to see it together with seeing owner of directory > /var/lib/sss/pipes/private > > ls -ld /var/lib/sss/pipes/private As above. > rpm -V sssd-common No output. Which is not surprising given the above update. (In reply to Brian J. Murrell from comment #11) > (In reply to Lukas Slebodnik from comment #10) > > But group owner of /var/lib/sss/pipes/private should be different (root and > > not sssd). > > This is the current state: > > # ls -l /var/lib/sss/pipes/ > total 4 > srw-rw-rw-. 1 root root 0 Aug 12 07:05 nss > srw-rw-rw-. 1 root root 0 Aug 12 07:05 pac > srw-rw-rw-. 1 root root 0 Aug 12 07:05 pam > drwxr-x---. 2 sssd root 4096 Aug 12 07:05 private > srw-rw-rw-. 1 root root 0 Aug 12 07:05 ssh > srw-rw-rw-. 1 root root 0 Aug 12 07:05 sudo > > So some "latent" change? Maybe the change to root was only effected by a > reboot (which really should not have been necessary). > > > BTW you didn't provide output of command "rpm -V sssd-common" > > Oh, sorry. I misread the condition on which you were looking for that. > > > > and it would be good to to see it together with seeing owner of directory > > /var/lib/sss/pipes/private > > > > ls -ld /var/lib/sss/pipes/private > > As above. > > > rpm -V sssd-common > > No output. Which is not surprising given the above update. It is not surprising. It is expected result. Becasue it is exactly the same as we have in spec file. %attr(750,sssd,root) %dir %{pipepath}/private You would see some output only in case of mismatch between expected rpm and current state. Are you still able to reproduce AVCs with default selinux policy? Not so far. I'll wait a week and if there is not any new comment I'll assume you cannot reproduce. So I'' close this BZ as "works for me" Sounds good. In agreement with comments #15 and #14, I'm closing this bug report as WORKSFORME. |
Description of problem: Trying to use saslauthd to use PAM to verify passwords in an IPA/sssd environment fails. Version-Release number of selected component (if applicable): selinux-policy-3.13.1-60.el7_2.9.noarch How reproducible: 100% Steps to Reproduce: 1. Build up an IPA/sssd environment 2. Install saslauthd 3. Use /usr/sbin/testsaslauthd -u ... -p ... to test saslauthd Actual results: Fails and generates AVCs: type=AVC msg=audit(1475994993.388:55701): avc: denied { dac_override } for pid=16878 comm="saslauthd" capability=1 scontext=system_u:system_r:saslauthd_t:s0 tcontext=system _u:system_r:saslauthd_t:s0 tclass=capability type=AVC msg=audit(1475994993.388:55701): avc: denied { dac_read_search } for pid=16878 comm="saslauthd" capability=2 scontext=system_u:system_r:saslauthd_t:s0 tcontext=sys tem_u:system_r:saslauthd_t:s0 tclass=capability type=SYSCALL msg=audit(1475994993.388:55701): arch=c000003e syscall=4 success=no exit=-13 a0=7f0a45f30e30 a1=7fff7a55ef20 a2=7fff7a55ef20 a3=7f0a461322c0 items=0 ppid=1 pid=168 78 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="saslauthd" exe="/usr/sbin/saslauthd" subj=system_u:system_r:saslauthd _t:s0 key=(null) Expected results: Should succeed. Additional info: Some strace debugging on where saslauthd is getting an EACCES reveals: getuid() = 0 getgid() = 0 stat("/var/lib/sss/pipes/private/pam", 0x7fff7a55ef20) = -1 EACCES (Permission denied) And we can see that a dac_override would be necessary: # ls -ld /var/lib/sss/pipes/private drwx------. 2 sssd sssd 4096 Sep 26 14:05 /var/lib/sss/pipes/private Temporarily changing the permission of the above to 777 with setenforce 1 and the saslauthd test works. But perhaps dac_override is not the right solution and something else is needed to prevent the need for the dac_override/dac_read_search.