Bug 551397 - libvirt shouldn't have to relabel public_content_t
libvirt shouldn't have to relabel public_content_t
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Eric Blake
Fedora Extras Quality Assurance
: 568763 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-12-30 08:31 EST by John L Magee
Modified: 2012-01-11 19:26 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-01-11 19:26:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John L Magee 2009-12-30 08:31:44 EST

SELinux is preventing /usr/bin/qemu-kvm "read" access on /dev/sr0.

Detailed Description:

SELinux denied access requested by qemu-kvm. It is not expected that this access
is required by qemu-kvm and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug

Additional Information:

Source Context                system_u:system_r:svirt_t:s0:c264,c650
Target Context                system_u:object_r:removable_device_t:s0
Target Objects                /dev/sr0 [ blk_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           qemu-system-x86-0.11.0-12.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-59.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed)
                     #1 SMP Mon Dec 21
                              05:33:33 UTC 2009 x86_64 x86_64
Alert Count                   24
First Seen                    Wed 30 Dec 2009 08:26:31 AM EST
Last Seen                     Wed 30 Dec 2009 08:30:28 AM EST
Local ID                      00d1d547-8eb4-4ae0-9fba-15c7f09f0c65
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1262179828.659:55): avc:  denied  { read } for  pid=2598 comm="qemu-kvm" path="/dev/sr0" dev=tmpfs ino=3525 scontext=system_u:system_r:svirt_t:s0:c264,c650 tcontext=system_u:object_r:removable_device_t:s0 tclass=blk_file

node=(removed) type=SYSCALL msg=audit(1262179828.659:55): arch=c000003e syscall=0 success=no exit=-13 a0=a a1=7f83221d5200 a2=800 a3=0 items=0 ppid=1 pid=2598 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c264,c650 key=(null)

Hash String generated from  selinux-policy-3.6.32-59.fc12,catchall,qemu-kvm,svirt_t,removable_device_t,blk_file,read
audit2allow suggests:
audit2allow is not installed.
Comment 1 Daniel Walsh 2009-12-30 08:46:18 EST
I am not sure if the device got mislabeled after libvirt started the image.  Did you insert the cdrom after the virtual machine was running?  libvirt is supposed to label the device, but if udev came in and relabeled it, this could happen.
Comment 2 John L Magee 2009-12-30 09:33:38 EST
I believe in this particular case, I did insert the data DVD after the VM was running. However, I get the same or similar failures even if the device is connected while the VM is shut down and then the VM is booted.

This failure occurs on a Lenovo T500 with a SATA CD/DVD drive. 

I have a nearly identical installation on a Lenovo T61p with IDE CD/DVD and can dynamically connect and disconnect the drive with no problem.
Comment 3 Daniel Walsh 2010-03-01 08:57:10 EST
*** Bug 568763 has been marked as a duplicate of this bug. ***
Comment 4 Daniel Walsh 2010-03-01 09:04:32 EST
I think we just need to add


To allow svirt_t to read files labeled as public_content_t blk devices labeled as removable_t.  Maybe add a boolean to read public_content and turn on by default.

virt_use_public_content  or something like that.  

But a bigger problem comes up when libvirt relabels public_content_t or removable_device_t to svirt_content_t.   This will prevent other apps from using the content.
Comment 5 Daniel Walsh 2010-03-01 09:07:36 EST
Anyone currently having this problem can build a custom policy module to allow this access

# cat > mysvirt.te << _EOF
policy_module(mysvirt, 1.0)
          type svirt_t;


# make -f /usr/share/selinux/devel/Makefile
# semodule -i mysvirt.pp
Comment 6 Cole Robinson 2010-03-01 11:08:15 EST
Hmm, how does libvirt determine what selinux labels qemu can access? Is there a programmatic way, or is this all hardcoded somewhere? It would suck if libvirt had to be patched to leave public_content_t alone.
Comment 7 Daniel Walsh 2010-03-01 11:15:17 EST
Yes it can check programatically 

For example

sesearch -A -s svirt_t -t public_content_t -p read

Returns nothing, versus

# sesearch -A -s svirt_t -t usr_t -p read
Found 3 semantic av rules:
   allow virt_domain usr_t : file { ioctl read getattr lock open } ; 
   allow virt_domain usr_t : dir { ioctl read getattr lock search open } ; 
   allow virt_domain usr_t : lnk_file { read getattr } ; 

Another choice would be to not relabel read/only content and rely on the administrator labeling stuff correctly and selinux-policy allowing


THen removeable_t labeled by udev and admins labeling public_content_t would just work.  

I am not sure what is best here.
Comment 8 Bug Zapper 2010-11-03 22:14:27 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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: 
Comment 9 Cole Robinson 2010-11-17 14:14:22 EST
I assume this is still a problem for f14, so reassigning.
Comment 10 Fedora Admin XMLRPC Client 2011-09-22 13:56:47 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora Admin XMLRPC Client 2011-09-22 13:59:58 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora Admin XMLRPC Client 2011-11-30 14:56:14 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora Admin XMLRPC Client 2011-11-30 14:59:23 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Fedora Admin XMLRPC Client 2011-11-30 15:02:34 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Fedora Admin XMLRPC Client 2011-11-30 15:03:28 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 16 Eric Blake 2011-12-06 22:46:31 EST
Reassigning to rawhide, as this is still not solved.  However, this upstream thread points to a possible solution to letting the user provide XML to override libvirt's default desire to label a particular disk, allowing the user to leave the public_content_t label untouched (if they also added the policy to allow svirt_t to access public_content_t): https://www.redhat.com/archives/libvir-list/2011-December/msg00297.html
Comment 17 Daniel Walsh 2011-12-07 12:15:25 EST
svirt_t is allowed to read public content in F16 and Rawhide.
Comment 18 Eric Blake 2012-01-11 19:26:12 EST
Additionally, libvirt 0.9.9 allows per-disk overrides (which can be used to avoid relabeling):

commit 6cb4acce8b136e0dd2afa647b9b8cdf7c1702aed
Author: Eric Blake <eblake@redhat.com>
Date:   Thu Dec 22 17:47:49 2011 -0700

    seclabel: extend XML to allow per-disk label overrides
    When doing security relabeling, there are cases where a per-file
    override might be appropriate.  For example, with a static label
    and relabeling, it might be appropriate to skip relabeling on a
    particular disk, where the backing file lives on NFS that lacks
    the ability to track labeling.  Or with dynamic labeling, it might
    be appropriate to use a custom (non-dynamic) label for a disk
    specifically intended to be shared across domains.
    The new XML resembles the top-level <seclabel>, but with fewer
    options (basically relabel='no', or <label>text</label>):
    <domain ...>
        <disk type='file' device='disk'>
          <source file='/path/to/image1'>
            <seclabel relabel='no'/> <!-- override for just this disk -->
        <disk type='file' device='disk'>
          <source file='/path/to/image1'>
            <seclabel relabel='yes'> <!-- override for just this disk -->
      <seclabel type='dynamic' model='selinux'>
        <baselabel>text</baselabel> <!-- used for all devices without override -->

I'm closing this bug.

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