various programs communicating with SSSD

Miroslav Grepl mgrepl at redhat.com
Thu Oct 2 17:30:08 UTC 2014


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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Basically we cover by

auth_use_nsswitch()

interface.


More information about the selinux mailing list