Description of problem: Trying to save a qemu-kvm domain creates a bunch of AVCs type=1400 audit(1242911515.624:1762): avc: denied { read } for pid=16904 comm="qemu-kvm" name="sh" dev=sda1 ino=57348 scontext=system_u:system_r:svirt_t:s0:c11,c221 tcontext=system_u:object_r:bin_t:s0 tclass=lnk_file type=1400 audit(1242911715.550:1764): avc: denied { execute } for pid=16961 comm="qemu-kvm" name="bash" dev=sda1 ino=57347 scontext=system_u:system_r:svirt_t:s0:c11,c221 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=1400 audit(1242911927.337:1766): avc: denied { read open } for pid=17048 comm="qemu-kvm" name="bash" dev=sda1 ino=57347 scontext=system_u:system_r:svirt_t:s0:c196,c518 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=1400 audit(1242913178.429:1768): avc: denied { execute_no_trans } for pid=17123 comm="qemu-kvm" path="/bin/bash" dev=sda1 ino=57347 scontext=system_u:system_r:svirt_t:s0:c583,c634 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=1400 audit(1242913246.675:1770): avc: denied { getattr } for pid=17187 comm="sh" path="/bin/bash" dev=sda1 ino=57347 scontext=system_u:system_r:svirt_t:s0:c606,c973 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=1400 audit(1242913246.677:1771): avc: denied { getattr } for pid=17187 comm="sh" path="/bin/dd" dev=sda1 ino=57386 scontext=system_u:system_r:svirt_t:s0:c606,c973 tcontext=system_u:object_r:bin_t:s0 tclass=file Version-Release number of selected component (if applicable): selinux-policy-3.6.12-34.fc11.noarch libvirt-0.6.2-8.fc11.x86_64 qemu-common-0.10.4-4.fc11.x86_64 How reproducible: 100% Steps to Reproduce: 1. virsh 'save domain /var/lib/libvirt/qemu/domain' Actual results: lot of denials; domain not saved properly and can not be restored
I can allow the execution of this, but I believe we are going to have a hard time with isolation here. What exactly is qemu saving? Is it rewriting an image file? If you put the machine or svirt_t in to permissive mode what do all of the avc's look like?
Urgh. This is an example of why the QEMU save capability is really evil. QEMU removed the old built-in 'save to file' capability, and todo this now you have to use their migrate API, telling it to exec 'dd of=/path/to/save'. We really need the build-in 'save to file' capability to come back so we can stop exec'ing bash, and dd for this purpose.
Ok I have duplicated this on my machine. Looks like libvirt creates a file and tells qemu to append to the file. So I don't have to give great privs to make this work. Fixed in selinux-policy-3.6.12-40.fc11.noarch
Image does stop running when I tell it to save which seems wrong though.
I think that stopping the virtual machine is expected. 'savevm' stores memory + processor content (at least, accordingly its documentation); keeping the machine alive might modify harddisk content and there might be a conflict when restored machine sees old processor/memory but new harddisk content.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've also duplicated this on my machine, Fedora 11, 64-bit, SE Linux=enforcing. This occurs with any save. I've done a recent update to my system. Daniel, I see your comment (#3 above) and I still have this problem, even though: [root@fedora-11-sys ~]# rpm -qa | grep selinux-policy selinux-policy-targeted-3.6.12-78.fc11.noarch selinux-policy-3.6.12-78.fc11.noarch