Bug 753396

Summary: virsh iface-start and iface-destroy commands lead to a "very long wait" before finally succeeding
Product: Red Hat Enterprise Linux 6 Reporter: Laine Stump <laine>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: high    
Version: 6.2CC: ajia, dominick.grift, dwalsh, jrieden, ksrot, mgrepl, mmalik, mshao, rwu
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-127.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 753395 Environment:
Last Closed: 2012-06-20 12:28:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 753395    
Bug Blocks: 754802    

Description Laine Stump 2011-11-12 08:19:28 UTC 
+++ This bug was initially created as a clone of Bug #753395 +++

Description of problem:

With "setenforce enforcing" and NetworkManager enabled, any use of libvirt's "virsh iface-start" or "virsh iface-destroy" commands leads to a very long delay (didn't time it, but at least one minute) before the command finally succeeds. During this time, /var/log/audit/audit.log shows the following AVC about once per second:

type=USER_AVC msg=audit(1321058847.893:372): user pid=1906 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.103 spid=1917 tpid=10568 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

How reproducible: 100%


Steps to Reproduce:
1. enable NetworkManager (may not be necessary, haven't checked)
2. setenforce enforcing
3. virsh iface-destroy [some interface you can live without for a minute]
  
Actual results:

Very long wait before success

Expected results:

Success within a few seconds (may take several seconds if using DHCP on the interface)

Additional info:

virsh iface-start and virsh iface-destroy are simply calling functions in the netcf library that exec /sbin/ifup and /sbin/ifdown. These shell scripts then call nmcli to do the actual work. dbus-daemon then at some point tries to send a message to nmcli. For some reason, rather than failing immediately, it retries about once a second for a long time, and then the operation succeeds anyway (not the send-msg, but the higher level "ifup/ifdown" operation).

ncftool has similar commands "ncftool ifup" and "ncftool ifdown" which succeed immediately as expected.

On eparis' advice, I created the following temporary policy module, which fixed the problem on my system:

module nmvirttemp 1.0;

require {
	type virtd_t;
	type NetworkManager_t;
	class dbus send_msg;
}

#============= NetworkManager_t ==============
allow NetworkManager_t virtd_t:dbus send_msg;

After discovering this problem on F16, I checked my F14 box and it has the same problem, so I assume it's also a problem on F14. I'm not sure when this crept in - I always run all my boxes with selinux enforcing, but hadn't done anything with these functions recently.
Comment 2 Laine Stump 2011-11-12 08:33:27 UTC 
I've verified that RHEL6 has the same problem, and it's fixed by the same policy addition, so I created this bug to track getting the fix into RHEL6.
Comment 4 Miroslav Grepl 2011-11-16 09:09:43 UTC 
Fixed in selinux-policy-3.7.19-127.el6
Comment 7 Laine Stump 2012-01-06 19:42:30 UTC 
The only infrastructure needed to test this is an interface on the test machine that can be "ifdown"ed for a minute without losing access to the machine (i.e. either a machine where you have access to the console, or a machine where there is more than one ethernet interface).

For example, let's say you have a machine with interface eth0 and you have access to the console. To reproduce the problem / verify the fix, just do the following:

1) install libvirt (if it's not already installed)

2) log into the console as root.

3) run this command: "virsh iface-destroy eth0"

If the problem is fixed, the command will succeed within a couple seconds. If the problem still exists, the command will hang for a minute or two before finally returning success. (once the interface is down, it can be brought back up with "virsh iface-start eth0" or "/sbin/ifup eth0"

If you want to create host bridges, bonds, etc and test the virsh iface-destroy and iface-start commands on them, you can do that too, but I believe they will utlize the same policy rules as a physical ethernet.
Comment 10 errata-xmlrpc 2012-06-20 12:28:48 UTC 
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-2012-0780.html