sssd failing with executable stack error (SELinux)

[chakkerz]

In particular this error

[root@cwaiprod1 ~]# service sssd start
Starting sssd: /usr/sbin/sssd: error while loading shared libraries:
libcrypto.so.0.9.8: cannot enable executable stack as shared object
requires: Permission denied
[FAILED]

which relates to the audit trail:

host=cwaiprod1.example.org type=AVC msg=audit(1313372860.204:1388): avc:
denied { execstack } for pid=6939 comm="sssd"
scontext=user_u:system_r:sssd_t:s0 tcontext=user_u:system_r:sssd_t:s0
tclass=process

host=cwaiprod1.example.org type=AVC msg=audit(1313372860.204:1388): avc:
denied { execmem } for pid=6939 comm="sssd"
scontext=user_u:system_r:sssd_t:s0 tcontext=user_u:system_r:sssd_t:s0
tclass=process

host=cwaiprod1.example.org type=SYSCALL msg=audit(1313372860.204:1388):
arch=c000003e syscall=10 success=yes exit=0 a0=7fffbeebb000 a1=1000
a2=1000007 a3=4 items=0 ppid=6938 pid=6939 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=4294967295
comm="sssd" exe="/usr/sbin/sssd" subj=user_u:system_r:sssd_t:s0 key=(null)

However on it's partner (the dev box) this works just fine, even though ldd indicates they (were) are using the same libraries. Turns out though that the libcrypto in question comes from the zend stack, which i excluded by editing the ldconfig configuration. That in turn made it start and all was good, right up the point where we wanted to verify that this wouldn't break on reboot, which is where we upgraded the dev host to be more identical (it was already working with sssd, and nevermind that our prod was running a newer version than the dev box).

I checked the getsebool output and allow_exec[mem|stack] are both on.

But i have noticed that on the prod node, ldd for /usr/sbin/sssd does report extra libraries.
Namely:
libcom_err.so.2 => /lib64/libcom_err.so.2
libcrypt.so.1 => /lib64/libcrypt.so.1
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3
libkeyutils.so.1 => /lib64/libkeyutils.so.1
libkrb5.so.3 => /usr/lib64/libkrb5.so.3
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
libselinux.so.1 => /lib64/libselinux.so.1
libsepol.so.1 => /lib64/libsepol.so.1

Does anyone know why one host is listing more libraries (they are supposed to be identical afterall), or why one cares about execstack while the other does not?

[sgallagh]

What version of SSSD was running on each of the boxes?

I'm concerned by "libcrypto.so.0.9.8: cannot enable executable stack as shared object" because SSSD isn't supposed to be linked against libcrypto at all (that comes from openssl and we use mozila-nss for crypto).

It's possible that you're using an old version of openldap-libs on one of these machines that predates the conversion to the mozilla-nss crypto.

[chakkerz]

Sorry, duh

[root@cwaidev1 booleans]# rpm -q sssd
sssd-1.5.1-37.el5
[root@cwaidev1 booleans]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
[root@cwaidev1 booleans]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted

The hosts are virtually identical (minor differences with prod not having the latest dbus, dm-multipath, kpartx, python-pygments, sendmail, tzdata, tk, and tix).

kernel is also the same at 2.6.18-274.el5 and the sebooleans are also identical.

Openldap ...yeah that did come up during the update when i stopped it looking at the zend libraries. I installed openldap24-libs because liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 was missing.

Both hosts have these on the nss front installed (yum install mozilla-nss tells me the latest nss is already installed citing the first two):

nss-3.12.8-4.el5_6						nss-3.12.8-4.el5_6
nss-3.12.8-4.el5_6						nss-3.12.8-4.el5_6
nss_db-2.2-35.4.el5_5					nss_db-2.2-35.4.el5_5
nss_db-2.2-35.4.el5_5					nss_db-2.2-35.4.el5_5
nss-tools-3.12.8-4.el5_6					nss-tools-3.12.8-4.el5_6

ironically, the host one which it works, only has openldap 2.3.x installed while the one where it isn't working has openldap24-libs extra:

openldap-2.3.43-12.el5_6.7				openldap-2.3.43-12.el5_6.7
openldap-2.3.43-12.el5_6.7				openldap-2.3.43-12.el5_6.7
							      >	openldap24-libs-2.4.23-5.el5
							      >	openldap24-libs-2.4.23-5.el5

installing the "missing" libraries on the dev host has no change in the output of ldd /usr/sbin/sssd :

[root@cwaidev1 booleans]# ldd /usr/sbin/sssd | grep zend
        liblber-2.4.so.2 => /usr/local/zend/lib/liblber-2.4.so.2 (0x00002aecf57ce000)
        libldap-2.4.so.2 => /usr/local/zend/lib/libldap-2.4.so.2 (0x00002aecf59db000)
        libsasl2.so.2 => /usr/local/zend/lib/libsasl2.so.2 (0x00002aecf5c21000)
        libssl.so.0.9.8 => /usr/local/zend/lib/libssl.so.0.9.8 (0x00002aecf5d39000)
        libcrypto.so.0.9.8 => /usr/local/zend/lib/libcrypto.so.0.9.8 (0x00002aecf5f89000)

overnight though, the output on the prod node ... looks like it has reverted to use zend AND it's output has the same number of lines as on the dev host ... and wouldn't start:

[root@cwaiprod1 lib]# ldd /usr/sbin/sssd
	linux-vdso.so.1 =>  (0x00007fff2dbfd000)
	libtevent.so.0 => /usr/lib64/libtevent.so.0 (0x0000003c50a00000)
	libtalloc.so.2 => /usr/lib64/libtalloc.so.2 (0x0000003c50e00000)
	libpopt.so.0 => /usr/lib64/libpopt.so.0 (0x0000003c4f200000)
	libldb.so.0 => /usr/lib64/libldb.so.0 (0x0000003c51a00000)
	libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x0000003c4c200000)
	libpcre.so.0 => /lib64/libpcre.so.0 (0x0000003c51200000)
	libini_config.so.2 => /usr/lib64/libini_config.so.2 (0x0000003c51e00000)
	libcollection.so.2 => /usr/lib64/libcollection.so.2 (0x0000003c4f600000)
	libdhash.so.1 => /usr/lib64/libdhash.so.1 (0x0000003c4fa00000)
	liblber-2.4.so.2 => /usr/local/zend/lib/liblber-2.4.so.2 (0x00002b370c2d6000)
	libldap-2.4.so.2 => /usr/local/zend/lib/libldap-2.4.so.2 (0x00002b370c4e3000)
	libtdb.so.1 => /usr/lib64/libtdb.so.1 (0x0000003c50200000)
	libssl3.so => /usr/lib64/libssl3.so (0x0000003c4ee00000)
	libsmime3.so => /usr/lib64/libsmime3.so (0x0000003c4d600000)
	libnss3.so => /usr/lib64/libnss3.so (0x0000003c4de00000)
	libnssutil3.so => /usr/lib64/libnssutil3.so (0x0000003c4e600000)
	libplds4.so => /usr/lib64/libplds4.so (0x0000003c4ea00000)
	libplc4.so => /usr/lib64/libplc4.so (0x0000003c4d200000)
	libnspr4.so => /usr/lib64/libnspr4.so (0x0000003c4da00000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c4ba00000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003c4b600000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003c4b200000)
	libcap.so.1 => /lib64/libcap.so.1 (0x0000003c4be00000)
	libpath_utils.so.1 => /usr/lib64/libpath_utils.so.1 (0x0000003c51600000)
	libref_array.so.1 => /usr/lib64/libref_array.so.1 (0x0000003c4fe00000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003c4e200000)
	libsasl2.so.2 => /usr/local/zend/lib/libsasl2.so.2 (0x00002b370c729000)
	libssl.so.0.9.8 => /usr/local/zend/lib/libssl.so.0.9.8 (0x00002b370c841000)
	libcrypto.so.0.9.8 => /usr/local/zend/lib/libcrypto.so.0.9.8 (0x00002b370ca91000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003c4ca00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003c4ae00000)
[root@cwaiprod1 lib]# service sssd restart
Stopping sssd:                                             [  OK  ]
Starting sssd: /usr/sbin/sssd: error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied
                                                           [FAILED]
[root@cwaiprod1 lib]# vi /etc/ld.so.conf.d/zend
zend_server.conf  zend-server.conf  
[root@cwaiprod1 lib]# vi /etc/ld.so.conf.d/zend_server.conf 
[root@cwaiprod1 lib]# vi /etc/ld.so.conf.d/zend-server.conf 
[root@cwaiprod1 lib]# ldconfig
[root@cwaiprod1 lib]# service sssd restart 
Stopping sssd: cat: /var/run/sssd.pid: No such file or directory
                                                           [FAILED]
Starting sssd:                                             [  OK  ]
[root@cwaiprod1 lib]#

... at least i know i can reliably get it back online if need be ...