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