Here is what I see in permissive mode:

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
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 installing a custom policy that allows transition from unconfined_r to iptables_t, 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;

Ok, I think we will need to remove virt_run() for unconfined_t.

If you execute

# service libvirtd restart 

then libvirtd should be running as system_r:virtd_t:s0-s0:c0.c1023

# ps -eZ |grep virtd

I have no idea what you are talking about, anyhow:

# ps -eZ |grep virtd
unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 28378 ? 00:00:00 libvirtd

Which is correct. So if you have libvirtd running as

unconfined_u:system_r:virtd_t:s0-s0:c0.c102

you are still getting this issue?

Hmm, this should explain what happened: I first got the wrong contexts, then I ran libvirtd from the command line to see the debug output more easily.  When I do that, the process runs as another context:

unconfined_u:unconfined_r:virtd_t:s0-s0:c0.c1023 1023 pts/1 00:00:00 libvirtd

audit.log then got spammed with these three SELinux errors.  Are people supposed to start libvirt (or other services) _exclusively_ through service?  They didn't tell me about it when I did RHCE, :) and I took it exactly to learn these nuances...

Well you should for both security reasons and to make sure SELinux works correctly.  The service script does a lot of scrubbing of the environment and transitions properly to the SELinux context.

http://danwalsh.livejournal.com/29041.html