CentOS virt - Jan 2010 - QEMU/KVM: SELinux denial on /dev/zero when starting a VM

Hi,

on an up to date CentOS 5.4 x86_64 (test machine), I systematically
get the following SELinux denial when I start a QEMU/KVM virtual
machine via virt-manager:

SELinux is preventing qemu-kvm (qemu_t) "execute" to /dev/zero
(zero_device_t).
(full alert below)

Running the command suggested by the alert (restorecon -v '/dev/zero')
does not solve the problem.

This does not prevent the VM to run, but I would like to better
understand what is happening here and the potential impact on
performance.
And if there is not impact, find a way to get rid of this warning...

Thanks in advance for any idea!

Mathieu


Summary:

SELinux is preventing qemu-kvm (qemu_t) "execute" to /dev/zero
(zero_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 /dev/zero,

restorecon -v '/dev/zero'

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:SystemLow-SystemHigh
Target Context                system_u:object_r:zero_device_t
Target Objects                /dev/zero [ chr_file ]
Source                        qemu-kvm
Source Path                   /usr/libexec/qemu-kvm
Port                          <Unknown>
Host                          alma
Source RPM Packages           kvm-83-105.el5_4.13
Target RPM Packages
Policy RPM                    selinux-policy-2.4.6-255.el5_4.1
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     alma
Platform                      Linux alma 2.6.18-164.9.1.el5 #1 SMP Tue Dec 15
                              20:57:57 EST 2009 x86_64 x86_64
Alert Count                   10
First Seen                    Tue 05 Jan 2010 05:12:20 AM CET
Last Seen                     Tue 05 Jan 2010 05:22:03 AM CET
Local ID                      8fb024fb-aa09-4177-84d7-55e5156e9538
Line Numbers

Raw Audit Messages

host=alma type=AVC msg=audit(1262665323.833:106): avc:  denied  {
execute } for  pid=8901 comm="qemu-kvm" path="/dev/zero"
dev=tmpfs
ino=2421 scontext=system_u:system_r:qemu_t:s0-s0:c0.c1023
tcontext=system_u:object_r:zero_device_t:s0 tclass=chr_file

host=alma type=SYSCALL msg=audit(1262665323.833:106): arch=c000003e
syscall=9 success=no exit=-13 a0=0 a1=2000 a2=7 a3=2 items=0 ppid=1
pid=8901 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/libexec/qemu-kvm"
subj=system_u:system_r:qemu_t:s0-s0:c0.c1023 key=(null)

> SELinux is preventing qemu-kvm (qemu_t) "execute" to /dev/zero
(zero_device_t).
> (full alert below)
I thought that maybe the latest selinux-policy update would fix this,
but after updating and 'sudo /sbin/restorecon -v /dev/zero' again, I
still have the same SELinux denial.

I browsed the CentOS bug tracker extensively (with search and browsing
the categories kvm, selinux-policy and selinux-policy-targeted) but
did not find a similar issue.

Should I book an issue in the bug tracker at this stage?
(I'm pretty surprised though that nobody encountered this, since it is
systematic, but my system is pretty much a vanilla CentOS 5.4 x86_64
with regard to SELinux and QEMU/KVM...)