Bug 631523

Summary: Suspending VMware virtual machines is slow or fails when selinux is enabled.
Product: Red Hat Enterprise Linux 6 Reporter: Ninad Ghodke <ninad>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.0CC: cward, ddumas, dwalsh, ebenes, mmalik, syeghiay
Target Milestone: rcKeywords: OtherQA, ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.7.19-55.el6 Doc Type: Bug Fix
Doc Text:
When SELinux was enabled, suspending VMware virtual machines was either slowed down, or failed. With this update, the relevant policy has been corrected, and VMware virtual machines are now suspended as expected.
Story Points: ---
Clone Of:
: 631981 (view as bug list) Environment:
Last Closed: 2011-05-19 11:54:50 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: 629274    
Bug Blocks: 637082    
Attachments:
Description Flags
audit.log none

Description Ninad Ghodke 2010-09-07 20:08:33 UTC
Created attachment 445773 [details]
audit.log

Description of problem:
This is tested using VMware Workstation 7.1.1 but applies to all the VMware products, this also applies to Fedora 13.


Version-Release number of selected component (if applicable):


How reproducible:
All the time.

Steps to Reproduce:
Using VMware Workstatino 7.1
1.Install RHEL6 in a VM.
2.Install tools after OS installation is complete.
3.Suspend the VM with the option or run the suspend script.

  
Actual results:
The VM does not suspend immediately. 
When the suspend command is issued, vmtoolsd which runs inside the VM executes the suspend script and the suspend script quiesces the networkmanager and brings down the network interfaces. But the dbus-send is unable to talk to the network-manager.

I shouldn't be able to see the process tree of when this happens... but I am able to see this.

oot 9918 0.0 0.3 60428 3108 ? Sl Jul30 2:40 /usr/sbin/vmtoolsd
root 26001 0.3 0.1 108136 1340 ? S 14:59 0:00 \_ /bin/sh /etc/vmware-tools/suspend-vm-default
root 26011 0.3 0.1 108400 1344 ? S 14:59 0:00 \_ /bin/sh /etc/vmware-tools/suspend-vm-default
root 26027 0.3 0.1 108396 1668 ? S 14:59 0:00 \_ /bin/bash ./ifdown ifcfg-lo
root 26033 0.0 0.0 108396 888 ? S 14:59 0:00 \_ /bin/bash ./ifdown ifcfg-lo
root 26034 0.3 0.1 51632 1976 ? S 14:59 0:00 \_ nmcli -t --fields running nm status
[root@localhost tmp]# strace -p 26034
Process 26034 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
writev(5, [{"l\1\0\1.\0\0\0\17\0\0\0\220\0\0\0\1\1o\0\37\0\0\0/org/fre"..., 160}, {"\36\0\0\0org.freedesktop.NetworkManag"..., 46}], 2) = 206
poll([{fd=5, events=POLLIN}], 1, 15000) = 0 (Timeout)
fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f83a295a000
writev(5, [{"l\1\1\1\214\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\207\0\0\0type='signal',sender='org.fr"..., 140}], 2) = 284
writev(5, [{"l\1\1\1\256\0\0\0\21\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\251\0\0\0type='signal',sender='org.fr"..., 174}], 2) = 318
writev(5, [{"l\1\1\1n\0\0\0\22\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"i\0\0\0type='signal',sender='org.fr"..., 110}], 2) = 254
writev(5, [{"l\1\1\1\244\0\0\0\23\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\237\0\0\0type='signal',sender='org.fr"..., 164}], 2) = 308
writev(5, [{"l\1\1\1\215\0\0\0\24\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\210\0\0\0type='signal',sender='org.fr"..., 141}], 2) = 285
writev(5, [{"l\1\1\1\256\0\0\0\25\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\251\0\0\0type='signal',sender='org.fr"..., 174}], 2) = 318
write(1, "running\n", 8) = 8
exit_group(0) = ?
Process 26034 detached



Expected results:
The VM should have suspended immediately.

Additional info:
To work around this.
1. I copied over just the single line in audit.log that has to do with dbus-send... see audit.log attached in the bug report.
2. cat /tmp/audit.log | audit2allow -M vmwareToolsSuspendResume 
3. semodule -i vmwareToolsSuspendResume.pp

so after this policy was installed the suspend resume script started working again.


the local.te file is

module vmwareToolsSuspendResume 1.0;

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

#============= NetworkManager_t ==============

allow NetworkManager_t init_t:dbus send_msg;

Comment 2 Daniel Walsh 2010-09-08 15:20:34 UTC
Miroslav add

	init_dbus_chat(NetworkManager_t)

Comment 5 Miroslav Grepl 2010-09-16 15:56:26 UTC
Fixed in selinux-policy-3.7.19-55.el6.noarch.

Comment 6 Chris Ward 2010-09-16 22:01:44 UTC
@vmware, if we pass you some updated bits, could you test to verify this issue is resolved?

Comment 8 Ninad Ghodke 2010-09-16 22:20:33 UTC
yes, could you let us know where to get the bits from?

Comment 9 Daniel Walsh 2010-09-17 13:16:43 UTC
http://people.redhat.com/SELinux/RHEL6/noarch

Comment 10 Chris Ward 2010-09-17 15:37:08 UTC
Or rather, http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/

Comment 12 Ninad Ghodke 2010-09-21 06:19:22 UTC
VMware QA has verified that this fixes the bug.
Thanks for the quick response.

Comment 14 Jaromir Hradilek 2010-10-14 12:17:17 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When SELinux was enabled, suspending VMware virtual machines was either slowed down, or failed. With this update, the relevant policy has been corrected, and VMware virtual machines are now suspended as expected.

Comment 16 errata-xmlrpc 2011-05-19 11:54:50 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0526.html