Re: various programs communicating with SSSD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/02/2014 02:32 PM, Milos Malik wrote:
Hi all,

I would like to ask for help to identify services / daemons / agents which communicate with SSSD. It seems that selinux-policy does not expect such a behavior in many cases. The idea struck me when Kyle Brantley filed following bug:
  * BZ#1147787 - zebra won't start when sssd is used due to selinux policy

As you can see the problem is not limited to RHEL-7 only:
  * BZ#1148572 - SELinux prevents zebra from communicating with sssd

Are there other services which would communicate with SSSD if SSSD was enabled ?

# grep sss /etc/nsswitch.conf
passwd:     sss files
shadow:     sss files
group:      sss files
#

Let's skip those SELinux domains which are already allowed to communicate with SSSD. Following script helped me to narrow the set of possible candidates:

for SCONTEXT in `seinfo -adomain -x | grep -v domain | sort` ; do
     COUNT=0
     sesearch -s $SCONTEXT -t sssd_var_lib_t -c sock_file -p write -A -C | grep -q allow && let "COUNT += 1"
     sesearch -s $SCONTEXT -t sssd_var_lib_t -c dir -p search -A -C | grep -q allow && let "COUNT += 1"
     sesearch -s $SCONTEXT -t sssd_t -c unix_stream_socket -p connectto -A -C | grep -q allow && let "COUNT += 1"
     sesearch -s $SCONTEXT -t sssd_public_t -c file -p read -A -C | grep -q allow && let "COUNT += 1"
     sesearch -s $SCONTEXT -t sssd_public_t -c dir -p search -A -C | grep -q allow && let "COUNT += 1"
     echo "$SCONTEXT: $COUNT"
done | grep -v ": 5"

The fact that selinux-policy does not contain appropriate allow rules for domain X does not mean that domain X does not want to communicate with SSSD. It's likely that nobody tried that scenario with enabled SELinux before.

So far I was able to reproduce AVCs in scenarios (on RHEL-7.0) when following domains communicated with SSSD:
  * openct_t
  * postgrey_t
  * drbd_t
  * sblim_gatherd_t
  * rhsmcertd_t
  * pkcsslotd_t
  * openvswitch_t
  * opensm_t
  * ddclient_t
  * mysqld_safe_t
  * conman_t
  * dnssec_trigger_t
  * ctdbd_t
  * nova_scheduler_t
  * nova_api_t
  * nova_network_t
  * nova_vncproxy_t
  * speech-dispatcher_t

I hope this email will help me create a list of domains, which suffer from similar SELinux denials, and start a discussion about possible ways how is (could be) SSSD used in SELinux enabled environments.

Milos Malik
SELinux QE person
Red Hat
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
Basically we cover by

auth_use_nsswitch()

interface.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux