Bug 441466 - SELinux prevents qemu/kvm to use logical volume device
Summary: SELinux prevents qemu/kvm to use logical volume device
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-08 09:14 UTC by Nils Philippsen
Modified: 2008-04-08 17:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-08 14:19:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nils Philippsen 2008-04-08 09:14:52 UTC
Description of problem:
When trying to use a logical volume as the system image of a qemu/kvm virtual
machine, accessing it is prohibited by SELinux policy (complete alert at the
bottom). "restorecon ..." on the device file or changing the
"allow_unconfined_qemu_transition" boolean didn't change anything, trying this
in permissive mode worked.

Version-Release number of selected component (if applicable):
selinux-policy-3.3.1-28.fc9.noarch
qemu-0.9.1-5.fc9.x86_64
kvm-64-3.fc9.x86_64

How reproducible:
Reproducible

Steps to Reproduce:
(0. Start libvirtd)
1. Start virt-manager
2. Connect virt-manager to the qemu hypervisor
3. Create a new virtual guest to be installed
4. ...
5. Use a logical volume, not a normal file, for installation
  
Actual results:
Prohibited by SELinux policy, virtual guest can't be created.

Expected results:
Virtual guest gets created, can be installed.

Additional info:
- Running existing guests from logical volumes doesn't work as well.
- This worked in F8.
- Complete alert:


Summary:

SELinux is preventing qemu-kvm (qemu_t) "read" to vg_gibraltar-lv_kvm_rawhide
(fixed_disk_device_t).

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:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for vg_gibraltar-lv_kvm_rawhide,

restorecon -v 'vg_gibraltar-lv_kvm_rawhide'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:qemu_t:s0
Target Context                system_u:object_r:fixed_disk_device_t:s0
Target Objects                vg_gibraltar-lv_kvm_rawhide [ blk_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          gibraltar
Source RPM Packages           kvm-64-3.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-28.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     gibraltar
Platform                      Linux gibraltar 2.6.25-0.200.rc8.git3.fc9.x86_64
                              #1 SMP Fri Apr 4 23:37:04 EDT 2008 x86_64 x86_64
Alert Count                   5
First Seen                    Tue 08 Apr 2008 10:57:57 AM CEST
Last Seen                     Tue 08 Apr 2008 11:13:33 AM CEST
Local ID                      16dbfec7-60ca-453b-b9ac-8f7c3da180e2
Line Numbers                  

Raw Audit Messages            

host=gibraltar type=AVC msg=audit(1207646013.598:112): avc:  denied  { read }
for  pid=21165 comm="qemu-kvm" name="vg_gibraltar-lv_kvm_rawhide" dev=tmpfs
ino=373 scontext=system_u:system_r:qemu_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

host=gibraltar type=SYSCALL msg=audit(1207646013.598:112): arch=c000003e
syscall=2 success=no exit=-13 a0=7fff39bc3c80 a1=0 a2=1a4 a3=391e16da10 items=0
ppid=2788 pid=21165 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm"
subj=system_u:system_r:qemu_t:s0 key=(null)

Comment 1 Daniel Walsh 2008-04-08 14:19:44 UTC
First we do not want to allow a confined qemu to read/write fixed_disk_device_t
since it could take over the entire machine.  So you have multiple options

If you are running qemu manually, you need to stop and restart the qemu after
setting

setsebool -P allow_unconfined_qemu_transition=0


An alternative would be to set the labeling on the blk_file to virt_image_t

chcon -t virt_image_t /PATHTO/vg_gibraltar-lv_kvm_rawhide

Which should allow qemu to use only this fixed disk.

If you wanted to make this permanant (survive a reboot)

semanage fcontext -a -t virt_image_t /PATHTO/vg_gibraltar-lv_kvm_rawhide




Comment 2 Nils Philippsen 2008-04-08 17:14:17 UTC
Cool, thanks for the info.


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