Description of problem: libvirt starts dnsmasq with --pid-file=/var/run/libvirt/network/default.pid but dnsmasq cannot write to virt_var_run_t # ls -Z /var/run/libvirt/network/ -rw-r--r--. root root unconfined_u:object_r:virt_var_run_t:s0 default.pid -rw-r--r--. root root unconfined_u:object_r:virt_var_run_t:s0 nwfilter.leases Version-Release number of selected component (if applicable): 0.9.13-3.el6 How reproducible: 100% Steps to Reproduce: yum install libvirt service libvirtd start virsh net-start default Actual results: Starting default network fails. Expected results: Starting default network works. Additional info: This error is also logged, will file a separate bug: type=SELINUX_ERR msg=audit(1343312370.260:393): security_compute_sid: invalid context unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=process
We have two issues. Could you try to execute # restorecon -R -v /var/run/libvirt/network/ # echo "type=SELINUX_ERR msg=audit(1343312370.260:393): security_compute_sid: invalid context unconfined_u:unconfined_r:iptables_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=process" | audit2allow -M mypol # semodule -i mypol.pp The problem is we have virtd_t running as unconfined_r which does a transition to iptables_t.
Restoring the contexts worked. I'm a bit puzzled as to why a normal installation of libvirt created wrong contexts, which is why I reported a separate bug for the transitions (bug 843544). Regarding the transitions, I also see these in permissive mode: type=SELINUX_ERR msg=audit(1343312811.896:525): security_compute_sid: invalid context unconfined_u:unconfined_r:dmidecode_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dmidecode_exec_t:s0 tclass=process type=SELINUX_ERR msg=audit(1343312811.732:520): security_compute_sid: invalid context unconfined_u:unconfined_r:dnsmasq_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dnsmasq_exec_t:s0 tclass=process In enforcing mode, dnsmasq is not launched because of the iptables problem. After doing the steps in comment 2, a "strace -ff -e execve libvirtd -v" indeed shows dnsmasq still failing to start: [pid 28089] execve("/usr/sbin/dnsmasq", ["/usr/sbin/dnsmasq", "--strict-order", "--bind-interfaces", "--pid-file=/var/run/libvirt/netw"..., "--conf-file=", "--except-interface", "lo", "--listen-address", "192.168.122.1", "--dhcp-range", "192.168.122.2,192.168.122.254", "--dhcp-leasefile=/var/lib/libvir"..., "--dhcp-lease-max=253", "--dhcp-no-override"], [/* 34 vars */]) = -1 EACCES (Permission denied) execve("/usr/sbin/dmidecode", ["/usr/sbin/dmidecode", "-q", "-t", "0,1,4,17"], [/* 34 vars */]) = -1 EACCES (Permission denied) So we need all of these: module mypol 1.0; require { type dmidecode_t; type iptables_t; type dnsmasq_t; role unconfined_r; } #============= ROLES ============== role unconfined_r types dmidecode_t; role unconfined_r types iptables_t; role unconfined_r types dnsmasq_t;
We should eliminate the transition from unconfined_t to svirt_t. like we have in Fedora.
Yes, I removed it.
Fixed in selinux-policy-3.7.19-159.el6
With selinux-policy-3.7.19-172.el6 We are seeing this AVC Denied message: time->Mon Oct 29 14:16:57 2012 type=SYSCALL msg=audit(1351534617.890:66): arch=c000003e syscall=2 success=no exit=-13 a0=170eaf0 a1=241 a2=1b6 a3=0 items=0 ppid=1 pid=7367 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dnsmasq" exe="/usr/sbin/dnsmasq" subj=unconfined_u:system_r:dnsmasq_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1351534617.890:66): avc: denied { write } for pid=7367 comm="dnsmasq" name="network" dev=dm-0 ino=1443806 scontext=unconfined_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=dir Regards, Jeff
I believe the network directory has a wrong label on it. DOes restorecon -R -v /var/run Fix it?
Dan, Not I am not 100% sure as this is seen in automated testing. If in fact it is mislabled then it is being done so at install time. I can try and stop the test before it gets to that point in testing and relabel the directory. Regards, Jeff
Miroslav, I think for RHEL6 we will just have to allow this, since I am not sure we can get this directory labeled correctly.
Is this a labeling problem under /var/run? restorecon -R -v /var/run
(In reply to comment #15) > Miroslav, I think for RHEL6 we will just have to allow this, since I am not > sure we can get this directory labeled correctly. I believe we need to allow it also for dhcpc_t.
Fine.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0314.html