Recording this against quantum for the moment. From enakai network node #============= dnsmasq_t ============== allow dnsmasq_t bin_t:dir read; allow dnsmasq_t bin_t:file { ioctl execute read open getattr execute_no_trans }; allow dnsmasq_t bin_t:lnk_file read; allow dnsmasq_t quantum_var_lib_t:dir search; #!!!! The source type 'dnsmasq_t' can write to a 'file' of the following types: # crond_var_run_t, virt_var_lib_t, dnsmasq_var_run_t, dnsmasq_var_log_t, dnsmasq_lease_t, root_t allow dnsmasq_t quantum_var_lib_t:file { write read getattr open }; allow dnsmasq_t shell_exec_t:file { read execute open getattr execute_no_trans }; #============= httpd_t ============== #!!!! This avc can be allowed using the boolean 'httpd_can_network_connect' allow httpd_t commplex_port_t:tcp_socket name_connect; #!!!! This avc can be allowed using the boolean 'httpd_can_network_connect' allow httpd_t glance_port_t:tcp_socket name_connect; #!!!! This avc can be allowed using the boolean 'httpd_tmp_exec' allow httpd_t httpd_tmp_t:file execute; #!!!! This avc can be allowed using one of the these booleans: # allow_ypbind, httpd_can_network_connect allow httpd_t port_t:tcp_socket name_connect; #!!!! This avc can be allowed using the boolean 'httpd_can_network_connect' allow httpd_t quantum_port_t:tcp_socket name_connect; #============= ifconfig_t ============== allow ifconfig_t anon_inodefs_t:file { read write }; allow ifconfig_t initrc_tmp_t:file { read write };
Please attach the AVC's not the allow rules. These are caused by a leak. allow ifconfig_t anon_inodefs_t:file { read write }; allow ifconfig_t initrc_tmp_t:file { read write };
Lon and I did a bit of pair-debugging on this... Here's the audit log: type=AVC msg=audit(1361296820.873:123253): avc: denied { read write } for pid=3316 comm="ip" path="anon_inode:[eventpoll]" dev=anon_inodefs ino=3654 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u\ :object_r:anon_inodefs_t:s0 tclass=file type=SYSCALL msg=audit(1361296820.873:123253): arch=c000003e syscall=59 success=yes exit=0 a0=14507d0 a1=127aaa0 a2=108b9b0 a3=0 items=0 ppid=2604 pid=3316 auid=4294967295 uid=164 gid=164 euid=164 suid=164 fsui\ d=164 egid=164 sgid=164 fsgid=164 tty=(none) ses=4294967295 comm="ip" exe="/sbin/ip" subj=system_u:system_r:ifconfig_t:s0 key=(null) It ppid 2604 is quantum-dhcp-agent: [root@bob-1 fd]# ps -eaf|grep 2604 quantum 2604 1 0 12:57 ? 00:00:03 python /usr/bin/quantum-dhcp-agent --log-file /var/log/quantum/dhcp-agent.log --config-file /usr/share/quantum/quantum-dist.conf --config-file /etc/quantum/quantu\ m root 31246 30827 0 14:29 pts/4 00:00:00 grep 2604 [root@bob-1 fd]# And it has a anon_inode FD open: [root@bob-1 fd]# pwd /proc/2604/fd [root@bob-1 fd]# ls -l total 0 lr-x------. 1 quantum quantum 64 Feb 19 14:16 0 -> /dev/null l-wx------. 1 quantum quantum 64 Feb 19 14:16 1 -> /dev/null l-wx------. 1 quantum quantum 64 Feb 19 14:16 10 -> pipe:[17353] lrwx------. 1 quantum quantum 64 Feb 19 14:16 11 -> socket:[17375] lr-x------. 1 quantum quantum 64 Feb 19 14:16 12 -> pipe:[17380] l-wx------. 1 quantum quantum 64 Feb 19 14:16 13 -> pipe:[17380] lrwx------. 1 quantum quantum 64 Feb 19 14:16 14 -> socket:[20873] l-wx------. 1 quantum quantum 64 Feb 19 14:16 2 -> /dev/null l-wx------. 1 quantum quantum 64 Feb 19 14:16 3 -> /var/log/quantum/dhcp-agent.log lr-x------. 1 quantum quantum 64 Feb 19 14:16 4 -> /dev/urandom lr-x------. 1 quantum quantum 64 Feb 19 14:16 5 -> pipe:[17329] l-wx------. 1 quantum quantum 64 Feb 19 14:16 6 -> pipe:[17329] lrwx------. 1 quantum quantum 64 Feb 19 14:16 7 -> anon_inode:[eventpoll] lrwx------. 1 quantum quantum 64 Feb 19 14:16 8 -> socket:[17348] lr-x------. 1 quantum quantum 64 Feb 19 14:16 9 -> pipe:[17353] [root@bob-1 fd]# So FD 7 in quantum-dhcp-agent seems to not have CLOEXEC set on it. We're guessing this FD is related to eventlet using poll. Lon is going to look at the eventlet code.
According to http://docs.python.org/2/library/subprocess.html#popen-constructor, we should be able to pass close_fds=True to subprocess.Popen() in quantum.agent.linux.utils.execute() to resolve this. I'll test this as soon as I can.
I removed the dependencies and the needinfo, since this was a quantum code issue rather than an SELinux policy issue (SELinux was kind enough to point out the problem).
Tested with latest openstack-quantum-2012.2.3-5.el6ost.noarch and latest selinux selinux-policy-targeted-3.7.19-195.el6_4.noarch selinux-policy-3.7.19-195.el6_4.noarch The AVCs abouve are not seen
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-0672.html