RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1383018 - selinux preventing saslauthd from using PAM and sssd
Summary: selinux preventing saslauthd from using PAM and sssd
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.2
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: sssd-qe
URL:
Whiteboard:
Depends On:
Blocks: 1393066
TreeView+ depends on / blocked
 
Reported: 2016-10-09 06:55 UTC by Brian J. Murrell
Modified: 2017-08-30 14:18 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-30 14:18:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Brian J. Murrell 2016-10-09 06:55:28 UTC 
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.
Comment 1 Brian J. Murrell 2016-10-09 06:57:58 UTC 
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.
Comment 3 Milos Malik 2016-10-10 11:33:58 UTC 
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
#
Comment 4 Brian J. Murrell 2016-10-11 13:15:45 UTC 
# 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
Comment 8 Lukas Slebodnik 2017-08-17 11:04:32 UTC 
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
Comment 9 Brian J. Murrell 2017-08-17 11:48:44 UTC 
(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.
Comment 10 Lukas Slebodnik 2017-08-17 12:39:08 UTC 
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
Comment 11 Brian J. Murrell 2017-08-17 12:57:26 UTC 
(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.
Comment 12 Lukas Slebodnik 2017-08-17 15:41:07 UTC 
(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?
Comment 13 Brian J. Murrell 2017-08-18 13:52:05 UTC 
Not so far.
Comment 14 Lukas Slebodnik 2017-08-18 13:56:05 UTC 
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"
Comment 15 Brian J. Murrell 2017-08-18 13:57:45 UTC 
Sounds good.
Comment 16 Jakub Hrozek 2017-08-30 14:18:18 UTC 
In agreement with comments #15 and #14, I'm closing this bug report as WORKSFORME.
Note You need to log in before you can comment on or make changes to this bug.