Bug 431615 - SELinux is preventing qemu-kvm (qemu_t) "getattr" to /dev/mapper/vol0-logRHEL5 (fixed_disk_device_t).
SELinux is preventing qemu-kvm (qemu_t) "getattr" to /dev/mapper/vol0-logRHEL...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-05 17:04 EST by Matěj Cepl
Modified: 2008-02-26 17:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-26 17:06:03 EST
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 Matěj Cepl 2008-02-05 17:04:59 EST
SELinux in the enforcing mode prevents kvm (or virsh) from creation of the
virtual machine, which works perfectly well with permissive mode of SELinux.

Summary from sealert:

SELinux is preventing qemu-kvm (qemu_t) "getattr" to /dev/mapper/vol0-logRHEL5
(fixed_disk_device_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

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 /dev/mapper/vol0-logRHEL5,

restorecon -v '/dev/mapper/vol0-logRHEL5'

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
Target Context                system_u:object_r:fixed_disk_device_t
Target Objects                /dev/mapper/vol0-logRHEL5 [ blk_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          hubmaier.ceplovi.cz
Source RPM Packages           kvm-56-1.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.2.6-2.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   catchall_file
Host Name                     hubmaier.ceplovi.cz
Platform                      Linux hubmaier.ceplovi.cz 2.6.24-9.fc9 #1 SMP Tue
                              Jan 29 17:45:59 EST 2008 x86_64 x86_64
Alert Count                   4
First Seen                    Tue Feb  5 22:47:25 2008
Last Seen                     Tue Feb  5 22:56:57 2008
Local ID                      88da2a0d-320d-445d-b796-d7c157a0359e
Line Numbers                  

Raw Audit Messages            

host=hubmaier.ceplovi.cz type=AVC msg=audit(1202248617.112:397): avc:  denied  {
getattr } for  pid=25674 comm="qemu-kvm" path="/dev/mapper/vol0-logRHEL5"
dev=tmpfs ino=337 scontext=system_u:system_r:qemu_t:s0
tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

host=hubmaier.ceplovi.cz type=SYSCALL msg=audit(1202248617.112:397):
arch=c000003e syscall=4 success=yes exit=0 a0=7fff202cbe6b a1=7fff202c3f40
a2=7fff202c3f40 a3=32ea56c9f0 items=0 ppid=2656 pid=25674 auid=4294967295 uid=0
gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="qemu-kvm"
exe="/usr/bin/qemu-kvm" subj=system_u:system_r:qemu_t:s0 key=(null)

Version of packages:
kvm-56-1.fc9.x86_64
selinux-policy-targeted-3.2.6-2.fc9.noarch
Comment 1 Jon Stanley 2008-02-05 19:05:00 EST
Reassigning to selinux-policy
Comment 2 Daniel Walsh 2008-02-06 08:47:14 EST
If you 

chcon -t virt_image_t /dev/mapper/vol0-logRHEL5

Does it work?

If it does then you can make this permanent by executing

semanage fcontext -a -t virt_image_t /dev/mapper/vol0-logRHEL5
Comment 3 Matěj Cepl 2008-02-06 10:32:01 EST
Yes, it helps. Isn't this something which should be included somewhere into
virt-install or to places like that?
Comment 4 Daniel Berrange 2008-02-06 10:40:42 EST
The Xen policy allows Xen to use any block device 'out of the box' - we should
really have parity with KVM / QEMU.  

Perhaps a boolean to toggle whether virtualization should have full access to
any block device vs requiring them to be explicitly labelled virt_image_t.


WHile using chcon/semanage works OK with LVM which has stable paths, it is more
problematic with regular disks because /dev/sd* is assigned on the fly at boot
time - so we prefer to use a stable path under /dev/disk/by-XXXX, but these are
just symlinks to labeling them doesn't help.
Comment 5 Daniel Walsh 2008-02-06 15:46:39 EST
Yes but allowing any confined domain to have R/W access to fixed device just
destroys the purpose for trying to confined them.  Since if I can r/w fixed
disk, I can change the file labels at will, and file labels are core to SELinux. 

We turned this on in Xen, since it was the only way to ship, and I hate having
it turned on.

Is there any way to setup the labeling before qemu starts?  virt-manager?
Comment 6 Jeremy Katz 2008-02-06 18:11:36 EST
People could easily run the qemu binaries by hand.  If we're going to be
successful in actually having people *not* turn off SELinux, we have to make
sure they're not prevented from using the tools they're used to rather than
forcing them to use something like virt-manager or libvirt.
Comment 7 Daniel Berrange 2008-02-06 21:01:21 EST
In the future libvirt will have SELinux support built in directly so you can
launch many VMs each in independant security contexts if desired, and it will
manage the block device / file contexts to match. This support is a little way
off in the future yet, and as jeremy mentions it doesn't really help people who
just use QEMU directly.
Comment 8 Daniel Walsh 2008-02-07 09:05:57 EST
Ok I will add a transition boolean to confine qemu when started by a user
directly defaulted to off.  So unconfind_transition_qemu.  This will by default
leave qemu\* in the unconfined_t when started by an unconfined user.  qemu will
transition when started from initrc_t or libvirtd_t.

Reasonable?
 
Comment 9 Daniel Walsh 2008-02-26 17:06:03 EST
Fixed in selinux-policy-3.3.1-4.fc9

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