Bug 450675 - virt-manager virDomainCreateLinux() failed due to SElinux issues
virt-manager virDomainCreateLinux() failed due to SElinux issues
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-10 07:31 EDT by Jonathan Underwood
Modified: 2009-07-14 11:01 EDT (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2008-06-10 07:31:59 EDT
Description of problem:
When trying to create a new virtual machine, virt-manager bombs with the
following dialogue box:

Unable to complete install: 'virDomainCreateLinux() failed internal error QEMU
quit during console startup
qemu: could not open disk image /home/jgu/w32/WindowsXP/WindowsXP.iso
'

The backtrace is:
Unable to complete install '<class 'libvirt.libvirtError'>
virDomainCreateLinux() failed internal error QEMU quit during console startup
qemu: could not open disk image /home/jgu/w32/WindowsXP/WindowsXP.iso

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 651, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 845, in
start_install
    return self._do_install(consolecb, meter)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 866, in
_do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.5/site-packages/libvirt.py", line 833, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: virDomainCreateLinux() failed internal error QEMU quit during
console startup
qemu: could not open disk image /home/jgu/w32/WindowsXP/WindowsXP.iso

'

The SElinux avc denial messages are:


Summary:

SELinux is preventing the qemu-system-x86 from using potentially mislabeled
files (./WindowsXP.iso).

Detailed Description:

SELinux has denied qemu-system-x86 access to potentially mislabeled file(s)
(./WindowsXP.iso). This means that SELinux will not allow qemu-system-x86 to use
these files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem is that
the files end up with the wrong file context which confined applications are not
allowed to access.

Allowing Access:

If you want qemu-system-x86 to access this files, you need to relabel them using
restorecon -v './WindowsXP.iso'. You might want to relabel the entire directory
using restorecon -R -v '.'.

Additional Information:

Source Context                unconfined_u:system_r:virtd_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                ./WindowsXP.iso [ file ]
Source                        qemu-system-x86
Source Path                   /usr/bin/qemu-system-x86_64
Port                          <Unknown>
Host                          withnail.phys.ucl.ac.uk
Source RPM Packages           qemu-0.9.1-5.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-62.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   home_tmp_bad_labels
Host Name                     withnail.phys.ucl.ac.uk
Platform                      Linux withnail.phys.ucl.ac.uk
                              2.6.25.4-30.fc9.x86_64 #1 SMP Wed May 21 17:34:18
                              EDT 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 10 Jun 2008 12:20:28 PM BST
Last Seen                     Tue 10 Jun 2008 12:20:28 PM BST
Local ID                      7e627683-dda4-4b19-a4a0-581e061cf75e
Line Numbers                  

Raw Audit Messages            

host=withnail.phys.ucl.ac.uk type=AVC msg=audit(1213096828.902:1858): avc: 
denied  { read } for  pid=29767 comm="qemu-system-x86" name="WindowsXP.iso"
dev=dm-1 ino=11829530 scontext=unconfined_u:system_r:virtd_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

host=withnail.phys.ucl.ac.uk type=SYSCALL msg=audit(1213096828.902:1858):
arch=c000003e syscall=2 success=no exit=-13 a0=7fff76f5ce30 a1=0 a2=1a4
a3=3714d67a70 items=0 ppid=29646 pid=29767 auid=500 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=207 comm="qemu-system-x86"
exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:virtd_t:s0 key=(null)


Summary:

SELinux is preventing the qemu-system-x86 from using potentially mislabeled
files (/home/jgu/w32/WindowsXP/WindowsXP.iso).

Detailed Description:

SELinux has denied qemu-system-x86 access to potentially mislabeled file(s)
(/home/jgu/w32/WindowsXP/WindowsXP.iso). This means that SELinux will not allow
qemu-system-x86 to use these files. It is common for users to edit files in
their home directory or tmp directories and then move (mv) them to system
directories. The problem is that the files end up with the wrong file context
which confined applications are not allowed to access.

Allowing Access:

If you want qemu-system-x86 to access this files, you need to relabel them using
restorecon -v '/home/jgu/w32/WindowsXP/WindowsXP.iso'. You might want to relabel
the entire directory using restorecon -R -v '/home/jgu/w32/WindowsXP'.

Additional Information:

Source Context                unconfined_u:system_r:virtd_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                /home/jgu/w32/WindowsXP/WindowsXP.iso [ file ]
Source                        qemu-system-x86
Source Path                   /usr/bin/qemu-system-x86_64
Port                          <Unknown>
Host                          withnail.phys.ucl.ac.uk
Source RPM Packages           qemu-0.9.1-5.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-62.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   home_tmp_bad_labels
Host Name                     withnail.phys.ucl.ac.uk
Platform                      Linux withnail.phys.ucl.ac.uk
                              2.6.25.4-30.fc9.x86_64 #1 SMP Wed May 21 17:34:18
                              EDT 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 10 Jun 2008 12:20:28 PM BST
Last Seen                     Tue 10 Jun 2008 12:20:28 PM BST
Local ID                      887bf1c9-eae9-432f-9eff-9d6170d1ae3a
Line Numbers                  

Raw Audit Messages            

host=withnail.phys.ucl.ac.uk type=AVC msg=audit(1213096828.902:1857): avc: 
denied  { getattr } for  pid=29767 comm="qemu-system-x86"
path="/home/jgu/w32/WindowsXP/WindowsXP.iso" dev=dm-1 ino=11829530
scontext=unconfined_u:system_r:virtd_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

host=withnail.phys.ucl.ac.uk type=SYSCALL msg=audit(1213096828.902:1857):
arch=c000003e syscall=4 success=no exit=-13 a0=7fff76f5ce30 a1=7fff76f5a420
a2=7fff76f5a420 a3=0 items=0 ppid=29646 pid=29767 auid=500 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=207 comm="qemu-system-x86"
exe="/usr/bin/qemu-system-x86_64" subj=unconfined_u:system_r:virtd_t:s0 key=(null)

It's clear what is going on here - the install media iso doesn't have the
SElinux label required by the SElinux policy. However, the situation is pretty
badly handled, I think. First off, virt-manager should test for this problem
before allocating the disk space. It should then also suggest some kind of work
around, eg. suggesting that the file be relabelled with the correct label,
whatever that is - in fact this could be optionally done by virt manager. On the
third hand, I think this SElinux policy restriction is a bit overly prohibitive.
Anyway, the user experience could be improved a lot here!



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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jonathan Underwood 2008-06-10 07:33:08 EDT
Opps, hit submit too early. Further info:

# rpm -qa | grep virt
libvirt-python-0.4.2-4.fc9.x86_64
virt-manager-0.5.4-4.fc9.x86_64
libvirt-0.4.2-4.fc9.x86_64
python-virtinst-0.300.3-7.fc9.noarch

# rpm -qa | grep selinux
libselinux-2.0.64-2.fc9.x86_64
selinux-policy-3.3.1-62.fc9.noarch
libselinux-python-2.0.64-2.fc9.x86_64
libselinux-2.0.64-2.fc9.i386
selinux-policy-targeted-3.3.1-62.fc9.noarch
Comment 2 Jason Taylor 2008-06-11 18:05:56 EDT
I tend to disagree, the two are mutually exclusive. VMM doesn't know about the
.iso to be used nor should it really be responsible for it, that should be the
users responsibility. As for the SELinux labeling, I agree, it should inherit
the labels from the home directory, why it doesn't I am not sure. It is a simple
fix though.
Comment 3 Jonathan Underwood 2008-06-11 19:35:47 EDT
The iso did have the label expected for a file in a user home directory though -
the point is that the SElinux policy as shipped requires an entirely different
label for the iso file for it to work with virt-manager (virtd_t). AFAIK, there
are no directives anywhere to tell the user to relabel his iso file to virtd_t
before attempting to use it to create a virtual machine. What I'd like to see is
virt-manager popping up a dialogue box saying "The iso file you have chosen for
the install media has the wrong SElinux label. Would you like me to label this
file with the correct label?". Or at the very least, "The iso image has the
wrong SElinux label, please ensure it is labelledd as virtd_t". Really, if the
SElinux policy is going to get this restrictive, applications have to start
being able to cope with SElinux denials cleanly, and not bombing out.

Also, virt-manager should check it can access the iso file *before* allocating
the image for the virtual machine, surely - in this case i waited for a few
minutes for a 10 GB disk image to be created. 
Comment 4 Cole Robinson 2008-06-13 15:17:53 EDT
I agree that this decision was not communicated clearly and we should attempt to
accomodate this in virt-manager in some way. A workaround should be to place the
iso file in /var/lib/libvirt/images which should have the correct labelling.

See http://danwalsh.livejournal.com/16589.html for some more info.
Comment 5 Bug Zapper 2009-06-09 21:31:03 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2009-07-14 11:01:31 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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