Hi. As i am running fedora core 20 and the updates from rawhide are far
than early ported to core i was wondering how to build it from source.
Do i just follow the INSTALL guide? It seems it installs as refpolicy
while i have targeted and mls or is it something non relevant? Do i have
to change the directive module-store to source from direct in
/etc/selinux/semanage.conf. Any other issues i should take care of?Thanks
Hi list. I think it would be nice to have an selinuxuser_udp_server
boolean identical to the selinuxuser_tcp_server. Issuing an sesearch -b
selinuxuser_tcp_server -AC would reveal little work to be done, but i
dont know how much rules would have to be written to the main selinux
Its just a thought but i would like some feedback.
I regularly report issues with confined users in SELinux as I run as one
on my day-to-day account. Sometimes I have contributed fixes to the
policy, but this has been through fedpkg and diffs that doesn't really
How do you (the main developers) setup your selinux policy, what git /
repo do you use for it, how do you build it etc.
Any tips would be appreciated so that I can setup a more "long lasting"
environment and hopefully, get to contribute some more policy.
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
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:
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.
SELinux QE person