Bug 491906 - virt is fubar
virt is fubar
Status: CLOSED DUPLICATE of bug 493692
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-24 11:59 EDT by Bill Nottingham
Modified: 2014-03-16 23:18 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-04 11:40: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 Bill Nottingham 2009-03-24 11:59:39 EDT
Description of problem:

type=AVC msg=audit(1237910177.043:171): avc:  denied  { read } for  pid=4783 comm="qemu-system-x86" name="boot.iso" dev=sda2 ino=5551920 scontext=system_u:system_r:svirt_t:s0:c753,c788 tcontext=system_u:object_r:virt_image_t:s0 tclass=file

Interestingly enough, the root fs for the image (not boot.iso) is *als* system_u:object_r:virt_image_t: ... and it's read fine.

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

selinux-policy-targeted-3.6.8-3.fc11.noarch
qemu-system-x86-0.10-0.9.kvm20090310git.fc11.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Attach a CDROM image to a F9 guest 
2. Attempt to boot
Comment 1 Daniel Walsh 2009-03-26 20:29:35 EDT
If you change the svirt image to svirt_image_t it should work.  Did you change the context of this image or did you copy it to a particular directory?

I just set a patch to virt-manager to label images automatically in the users home and /tmp directory.
Comment 2 Bill Nottingham 2009-03-27 10:51:49 EDT
Just downloaded the boot.iso directly (from a root shell) to /var/lib/libvirt/images.
Comment 3 Daniel Walsh 2009-03-27 15:20:16 EDT
WHat do you think about downloading to this directory instead?

/var/lib/libvirt/boot

Not that it would work now, but I do not want to allow svirt to rad all images in /var/lib/libvirt/images, which is currently labeled virt_image_t.  libvirt changes the context to svirt_image_t:MCS when the image is running and back to virt_image_t when it completes.  This prevents a running image from reading a non running image.

Shared storage and read only shared storage has to be labeled something that svirt can read.  Currently I am leaning toward virt_content_t.  Which I could label /var/lib/libvirt/boot and all svirt images could read.
Comment 4 Bill Nottingham 2009-03-27 15:22:57 EDT
The only reason I downloaded to /var/lib/libvirt/images is because that's where it needed to be for the proper context to be applied before sVirt came into play.

Do we have a flag day scenario here, where before sVirt you need to do X, but after you need to do Y?
Comment 5 Daniel Walsh 2009-03-27 15:31:07 EDT
Well I guess so.

With svirt we are trying to prevent one image from stealing information from another, which is why we are chaning the image labels. 

libvirt is doing a lot of relabeling now but not on readonly content.  So we need to label readonly content something different then a read/write image file and a read/write image file has to be labeled different then a read/write running image file.

So my current thinking is we label images files that are not running qemu_image_t:s0, images that are running svirt_image_t:MCS, shared and read/only content as virt_content_t:s0.  All users have to do is copy or install readonly content in a separate directory then the images directory to get labelling correct.

Currently default labeling for /var/lib/libvirt/isos is virt_content_t that way, but this
directory does not exist
Comment 6 Daniel Berrange 2009-03-27 15:58:58 EDT
If we have a 'svirt_content_t' then we could also consider having libvirt automatically label read-only files with this context, so anyone already using ISOs in /var/lib/libvirt/images  would not get broken.
Comment 7 Daniel Walsh 2009-03-27 16:53:26 EDT
Yes we can do that but we don't want to do this for devices.  /dev/cdrom for example, since we could remove rights to other non svirt processes that want to use the file/device.
Comment 8 Mark McLoughlin 2009-05-04 11:40:31 EDT
This looks like a dup of bug #493692, which has a patch

*** This bug has been marked as a duplicate of bug 493692 ***

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