This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 452671 - Make virt-manage more SELinux aware
Make virt-manage more SELinux aware
Status: CLOSED CURRENTRELEASE
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-24 09:15 EDT by James Morris
Modified: 2009-06-10 06:50 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-10 06:50:44 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 James Morris 2008-06-24 09:15:46 EDT
If a user configures a virtual machine with virt-manager, it would be useful if
virt-manage could verify that the SELinux labeling is correct for the vm image
location, and if not, correct the issue, so that users are not disrupted.

A suggested approach is to have a helper script which runs

# semanage fcontext -a
# restorecon
Comment 1 Jon Masters 2008-06-24 13:08:17 EDT
Personally, I don't think it's the place of virt-manager to make the labeling
change. But I might be wrong.
Comment 2 Stephen Smalley 2008-06-24 13:47:44 EDT
Whatever tool is used to create the image would ideally ensure that it is
properly labeled as well.  If the image is placed into a standard location, then
the default policy would cover it.  If not, then the tool could either
automatically run the necessary semanage and restorecon commands to add the
definition and apply it, or it could notify the user of the need to do that. 
setroubleshoot should of course have done likewise, but it would be better to
solve these issues up front before we ever encounter a denial than retroactively.
Comment 3 Stephen Smalley 2008-06-24 13:49:42 EDT
To be precise, the commands to run would be of the form:
semanage fcontext -a -t <proper type for image> "/path/to/image"
restorecon /path/to/image

The proper type for the image is policy-dependent, so we would want virt-manager
to get it from some policy config file or libselinux interface.
Comment 4 Daniel Berrange 2008-06-24 14:35:49 EDT
In libvirt we recently added code for storage management. This has the ability
to read and set the context on directories used for virtual disk images. We have
not hooked this capability upto virt-manager yet, but once we do, all virtual
disks will automatically get assigned the correct context. I suggest leaving
this BZ open to track porting of virt-manager to use  libvirt's storage APIs.
Comment 5 Cole Robinson 2008-06-24 14:44:51 EDT
Until that time though I think it would be a good idea to be able to check the
labeling of existing images and install media.

What are our options here besides calling out to cli tools? I see there is
libselinux-python, but is it overkill if we just want to determine we have
access to a file, and possibly recommend a corrective action to the user?
Comment 6 Daniel Walsh 2008-06-25 07:07:42 EDT
You could get the context of the default location and then set the context of
the new location.

/var/lib/libvirt/images

This would be a big step in the right direction, but it would not be 100% full
proof, since qemu and friends have got to be able to search all directories in
the path.

Setting the context of /virt/myimages/RHEL5.img

to virt_image_t
Would not solve the problem because /virt and /virtmyimages are labeled
default_t and probably not searchable by qemu.

Comment 7 Andrew Bartlett 2008-08-25 18:53:39 EDT
Also, in the desktop VM setting, it is quite common to wish to load CDs that are not stored with the virtual disks.  The failure mode for this is particularly poor, because these are permitted to be swapped at run time from the GUI, which does not present this restriction.
Comment 8 Daniel Walsh 2008-09-02 16:41:51 EDT
What avc's are you seeing?
Comment 9 Patrick C. F. Ernzer 2008-09-15 07:21:46 EDT
(In reply to comment #8)
> What avc's are you seeing?

FWIW: images on an existing FS work fine for me (fully updated F9), but using an LV fails with

type=AVC msg=audit(1221472991.953:46): avc:  denied  { getattr } for  pid=4384 comm="qemu-kvm" path="/dev/mapper/VG_x60_internal-KVM_RHEL5" dev=tmpfs ino=24585 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

and

type=AVC msg=audit(1221472991.954:47): avc:  denied  { read } for  pid=4384 comm="qemu-kvm" name="VG_x60_internal-KVM_RHEL5" dev=tmpfs ino=24585 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

(do tell if you'd rather have these in a separate bug.
Comment 10 Patrick C. F. Ernzer 2008-09-15 07:25:20 EDT
(In reply to comment #8 and #9)
> What avc's are you seeing?

Ah, doh!, anaconda was running happily but when I looked at the box next I had:

type=AVC msg=audit(1221477617.603:83): avc:  denied  { read } for  pid=7934 comm="qemu-kvm" name="RHEL5-i386.img" dev=dm-3 ino=1172344 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

(which makes sense as this image file is in my home)
Comment 11 Daniel Walsh 2008-09-15 12:38:37 EDT
/dev/mapper/VG_x60_internal-KVM_RHEL5 needs to be labeled virt_image_t

# semanage fcontext -a -t virt_image_t /dev/mapper/VG_x60_internal-KVM_RHEL5
# restorecon -v /dev/mapper/VG_x60_internal-KVM_RHEL5

The file you homedir would need a similar file context.  Although moving it to /var/lib/libvirt/images and running restorecon on it would be preffered.

There is work on to get virt-manager to label the images correctly automatically.
Comment 12 Chris Snook 2008-10-29 18:27:46 EDT
I'm seeing denials with logical volumes that were created by the new storage management code in virt-manager.  I created a volume group, added it as a storage pool in virt-manager, and then created an LV with virt-manager.  When I try to create a domain, I get this:

Unable to complete install '<class 'libvirt.libvirtError'> internal error QEMU quit during console startup
qemu: could not open disk image /dev/data/rawhide

sealert on the denial shows this:

node=fourier.jnsq.org type=AVC msg=audit(1225317869.835:153): avc:  denied  { read } for  pid=7573 comm="qemu-kvm" name="data-rawhide" dev=tmpfs ino=23453 scontext=unconfined_u:system_r:qemu_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

node=fourier.jnsq.org type=SYSCALL msg=audit(1225317869.835:153): arch=c000003e syscall=2 success=yes exit=0 a0=7fff0dc68650 a1=0 a2=1a4 a3=3dd6770a70 items=0 ppid=3589 pid=7573 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=unconfined_u:system_r:qemu_t:s0 key=(null)

So, it looks like the libvirt storage manager is not doing SELinux labeling for logical volumes.
Comment 13 Bug Zapper 2009-06-09 21:45:36 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 14 Daniel Walsh 2009-06-10 06:50:44 EDT
THis is largely accomplished by svirt. so I am closing this bug.  If you have problems with svirt then open new bugzillas.

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