This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 493692 - Creating new VM; SELinux prevents opening iso image of install media
Creating new VM; SELinux prevents opening iso image of install media
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
: Reopened
: 491906 493743 499027 (view as bug list)
Depends On:
Blocks: F12VirtBlocker
  Show dependency treegraph
 
Reported: 2009-04-02 13:18 EDT by Alex Hudson (Fedora Address)
Modified: 2009-07-03 05:59 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 05:59:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Relabel shared & readonly images (2.60 KB, patch)
2009-05-01 12:14 EDT, Daniel Berrange
no flags Details | Diff
Relabel shared & readonly images (2.60 KB, patch)
2009-05-05 08:41 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Alex Hudson (Fedora Address) 2009-04-02 13:18:34 EDT
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:
Comment 1 Alex Hudson (Fedora Address) 2009-04-03 03:45:26 EDT
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
Comment 2 Mark McLoughlin 2009-04-03 06:21:54 EDT
*** Bug 493743 has been marked as a duplicate of this bug. ***
Comment 3 Mark McLoughlin 2009-04-03 06:23:11 EDT
Could you post the SELinux errors? Also, 'ls -lZ' on the iso
Comment 4 Alex Hudson (Fedora Address) 2009-04-03 06:38:24 EDT
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
Comment 5 Cole Robinson 2009-04-21 16:47:02 EDT
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?
Comment 6 Daniel Walsh 2009-04-22 07:41:04 EDT
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.
Comment 7 Mark McLoughlin 2009-04-22 09:29:32 EDT
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 ?
Comment 8 Mark McLoughlin 2009-04-22 09:45:44 EDT
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
Comment 9 Daniel Walsh 2009-04-22 12:06:45 EDT
Yes although I do not believe we have fixed this code yet.  Dan have you worked on this?
Comment 10 Mark McLoughlin 2009-05-01 09:48:26 EDT
Dan and Dan, can one of you look at this? It's on the F11 blocker list, still in NEW and assigned to DV ...
Comment 11 Daniel Berrange 2009-05-01 12:14:47 EDT
Created attachment 342115 [details]
Relabel shared & readonly images

This is one potential patch impl.
Comment 12 Daniel Walsh 2009-05-01 13:10:23 EDT
Looks good to me.

I can make the policy work with that.  

Dan
Comment 13 Daniel Berrange 2009-05-01 13:47:12 EDT
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.
Comment 14 Daniel Walsh 2009-05-01 14:45:30 EDT
Yes leave them as svirt_t:s0 and virt_content_t:s0 always.
Comment 15 Daniel Walsh 2009-05-01 14:46:55 EDT
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.
Comment 16 Mark McLoughlin 2009-05-04 11:40:31 EDT
*** Bug 491906 has been marked as a duplicate of this bug. ***
Comment 17 Mark McLoughlin 2009-05-05 04:27:56 EDT
*** Bug 499027 has been marked as a duplicate of this bug. ***
Comment 18 Daniel Berrange 2009-05-05 08:41:36 EDT
Created attachment 342450 [details]
 Relabel shared & readonly images

Same as before, but skipping restore step.
Comment 19 Daniel Walsh 2009-05-05 08:54:05 EDT
Ok can we get this in before tomorrows svirt test?
Comment 20 Daniel Berrange 2009-05-05 09:17:25 EDT
Fix built into libvirt-0.6.2-4.fc11
Comment 21 Mark McLoughlin 2009-05-05 09:30:20 EDT
Tag request https://fedorahosted.org/rel-eng/ticket/1732
Comment 22 Mark McLoughlin 2009-05-05 12:31:40 EDT
Tagged now, closing
Comment 23 Mark McLoughlin 2009-07-03 05:48:32 EDT
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
Comment 24 Mark McLoughlin 2009-07-03 05:59:09 EDT
* Fri Jul  3 2009 Mark McLoughlin <markmc@redhat.com> - 0.6.4-3.fc12
- Handle shared/readonly image labelling (bug #493692)

Note You need to log in before you can comment on or make changes to this bug.