Description of problem: I'm attempting to create an OpenSUSE VM from an ISO I downloaded from their website. I'm doing this through virt-manager, but assume the bug must lie in libvirt or possibly qemu. I get the following error and then a python traceback: Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: qemu: could not open disk image /var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso I can't see any reason why the iso would be inaccessible: # ls /var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso -Z -rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso # ls /var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso -lh -rw-r--r--. 1 root root 118M 2009-04-02 17:29 /var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso Version-Release number of selected component (if applicable): libvirt-0.6.1-5.fc11.x86_64 qemu-0.10-0.12.kvm20090323git.fc11.x86_64 How reproducible: Steps to Reproduce: 1. Create new VM in virt-manager using an ISO image as install media 2. Click finish 3. Actual results: See above error message. Expected results: Additional info:
Apologies for the noise. I just tried disabling SELinux with "echo 0 >/selinu:/enforce"; my VM now works. Clearly, this is an SELinux problem, but as far as I know my disk image is both correctly labelled and in the right directory - what's going on here? :S
*** Bug 493743 has been marked as a duplicate of this bug. ***
Could you post the SELinux errors? Also, 'ls -lZ' on the iso
The ls -Z is in #c0. Excerpt from /var/log/messages: Apr 2 17:31:17 localhost kernel: type=1400 audit(1238689877.435:56): avc: denied { getattr } for pid=4886 comm="qemu-kvm" path="/var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso" dev=dm-0 ino=275 scontext=system_u:system_r:svirt_t:s0:c24,c488 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file Apr 2 17:31:17 localhost kernel: type=1300 audit(1238689877.435:56): arch=c000003e syscall=4 success=no exit=-13 a0=7fff475b3eb0 a1=7fff475b1550 a2=7fff475b1550 a3=7fff475b12f0 items=0 ppid=1 pid=4886 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c24,c488 key=(null) Apr 2 17:31:17 localhost kernel: type=1400 audit(1238689877.435:57): avc: denied { read } for pid=4886 comm="qemu-kvm" name="openSUSE-11.1-NET-x86_64.iso" dev=dm-0 ino=275 scontext=system_u:system_r:svirt_t:s0:c24,c488 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file Apr 2 17:31:17 localhost kernel: type=1300 audit(1238689877.435:57): arch=c000003e syscall=2 success=no exit=-13 a0=7fff475b3eb0 a1=1000 a2=1a4 a3=7fff475ae8c0 items=0 ppid=1 pid=4886 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c24,c488 key=(null) Apr 2 17:31:17 localhost kernel: virbr0: port 1(vnet0) entering disabled state Apr 2 17:31:17 localhost kernel: device vnet0 left promiscuous mode Apr 2 17:31:17 localhost kernel: type=1700 audit(1238689877.494:58): dev=vnet0 prom=0 old_prom=256 auid=500 uid=0 gid=0 ses=2 Apr 2 17:31:17 localhost kernel: virbr0: port 1(vnet0) entering disabled state Apr 2 17:31:17 localhost kernel: virbr0: topology change detected, propagating Apr 2 17:31:17 localhost kernel: virbr0: port 1(vnet0) entering forwarding state Apr 2 17:31:17 localhost NetworkManager: nm_device_ethernet_new: assertion `driver != NULL' failed Apr 2 17:31:17 localhost kernel: type=1400 audit(1238689877.435:56): avc: denied { getattr } for pid=4886 comm="qemu-kvm" path="/var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso" dev=dm-0 ino=275 scontext=system_u:system_r:svirt_t:s0:c24,c488 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file Apr 2 17:31:17 localhost kernel: type=1300 audit(1238689877.435:56): arch=c000003e syscall=4 success=no exit=-13 a0=7fff475b3eb0 a1=7fff475b1550 a2=7fff475b1550 a3=7fff475b12f0 items=0 ppid=1 pid=4886 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c24,c488 key=(null) Apr 2 17:31:17 localhost kernel: type=1400 audit(1238689877.435:57): avc: denied { read } for pid=4886 comm="qemu-kvm" name="openSUSE-11.1-NET-x86_64.iso" dev=dm-0 ino=275 scontext=system_u:system_r:svirt_t:s0:c24,c488 tcontext=unconfined_u:object_r:virt_image_t:s0 tclass=file Apr 2 17:31:17 localhost kernel: type=1300 audit(1238689877.494:58): arch=c000003e syscall=3 success=yes exit=0 a0=17 a1=0 a2=0 a3=4 items=0 ppid=1 pid=4535 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="libvirtd" exe="/usr/sbin/libvirtd" subj=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 key=(null) Apr 2 17:31:20 localhost libvirtd: 17:31:20.509: error : internal error Timed out while reading console log output Apr 2 17:31:20 localhost libvirtd: 17:31:20.509: error : internal error unable to start guest: qemu: could not open disk image /var/lib/libvirt/images/openSUSE-11.1-NET-x86_64.iso#012
I can reproduce this: # rpm -qa | grep selinux-policy selinux-policy-3.6.12-4.fc11.noarch selinux-policy-targeted-3.6.12-4.fc11.noarch Trying to use a file labelled as virt_image_t as a cdrom device throws an selinux error. Changing the label to virt_content_t fixes it. Attaching the originally labelled file as an IDE harddisk works as well. It seems to me that if virt_content_t is sufficient, than virt_image_t should be as well, but I can't claim to know much about this stuff. We should find a way to fix this though, since putting install media in /var/lib/libvirt/images was previously one of the recommended ways to avoid selinux issues. dwalsh, any suggestions?
The way the SELinux policy is currently setup: qemu process launched by libvirt will run as svirt_t:MCS where MCS is some random number guaranteed to be different for every qemu launched by libvirt on the current machine. Rules about svirt_t:MCS are svirt:MCS rwx on svirt_image_t:MCS svirt_image_t:MCS is only read/write/execute for svirt_t:MCS svirt:MCS rwx on svirt_image_t:s0 (No MCS Label) this file label is rwx by all svirt_t processes svirt_t:MCS ro virt_content_t All svirt_t processes can read virt_content_t files. svirt_t:MCS has NO access to virt_image_t:s0 When libvirt is finishes executing a svirt_t:MCS it relabels the svirt_image_t:MCS to virt_image_t:s0, This will prevent other svirt_t:MCS1 from reading the image, Think of svirt_t:COKE reading svirt_image_t:COKE, when it completes we want svirt_image_t:COKE relabeled to virt_image_t:s0 and this will prevent svirt_image_t:PEPSI from reading it. If it was virt_image_t it could be read by PEPSI, if it was svirt_image_t:s0 it could be read and written by PEPSI. /var/lib/libvirt/images defaults to virt_image_t so none of the svirt_t:MCS can read them UNLESS libvirt relabels them to a label the svirt_t:MCS is allowed to use.
dwalsh, thanks for the explanation, very useful If I understand you correctly, doesn't it sound like libvirt failed to re-label the iso with svirt_image_t:s0:c24,c488 ?
Is this the problem ? if (secdef->imagelabel) { for (i = 0 ; i < vm->def->ndisks ; i++) { if (vm->def->disks[i]->readonly || vm->def->disks[i]->shared) continue; If an image is virt_image_t, it needs to be re-labelled even if its only going to be used read-only
Yes although I do not believe we have fixed this code yet. Dan have you worked on this?
Dan and Dan, can one of you look at this? It's on the F11 blocker list, still in NEW and assigned to DV ...
Created attachment 342115 [details] Relabel shared & readonly images This is one potential patch impl.
Looks good to me. I can make the policy work with that. Dan
There's one minor flaw in that patch I posted, in that it restores the label upon guest shutdown. This is wrong for readonly/shared disks, because they may still be in use in other VMs. I think i'll probably change it to simply not do anything for these disks types on shutdown. Longer term we should possibly check all active VMs to see if the disk is in use or not.
Yes leave them as svirt_t:s0 and virt_content_t:s0 always.
From a security point of view makes no difference if you relabel them since they are temparily svirt_t:s0 and virt_content_t:s0. Any running virtual machine could have used them when they were labeled that way. So chaning them to some other context would be pointless.
*** Bug 491906 has been marked as a duplicate of this bug. ***
*** Bug 499027 has been marked as a duplicate of this bug. ***
Created attachment 342450 [details] Relabel shared & readonly images Same as before, but skipping restore step.
Ok can we get this in before tomorrows svirt test?
Fix built into libvirt-0.6.2-4.fc11
Tag request https://fedorahosted.org/rel-eng/ticket/1732
Tagged now, closing
Patch never got upstream, was dropped by the 0.6.4 rebase in F-12, re-opening Patch posted upstream here: http://www.redhat.com/archives/libvir-list/2009-July/msg00048.html Hopefully will be in 0.6.5
* Fri Jul 3 2009 Mark McLoughlin <markmc> - 0.6.4-3.fc12 - Handle shared/readonly image labelling (bug #493692)