Bug 882258

Summary: SELinux is preventing /usr/bin/qemu-kvm from 'read, write' accesses on the chr_file /dev/tap32
Product: [Fedora] Fedora Reporter: Vladislav Grigoryev <vg.aetera>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: charlieb-fedora-bugzilla, dominick.grift, dwalsh, eparis, mgrepl, pmoore, ryanm, vg.aetera
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-07 07:18:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Vladislav Grigoryev 2012-11-30 14:14:09 UTC
Description of problem:
SELinux is preventing /usr/bin/qemu-kvm from 'read, write' accesses on the chr_file /dev/tap32.

*****  Plugin restorecon (85.9 confidence) suggests  *************************

If you want to fix the label. 
/dev/tap32 default label should be tun_tap_device_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /dev/tap32

*****  Plugin device (9.04 confidence) suggests  *****************************

If you want to allow qemu-kvm to have read write access on the tap32 chr_file
Then you need to change the label on /dev/tap32 to a type of a similar device.
Do
# semanage fcontext -a -t SIMILAR_TYPE '/dev/tap32'
# restorecon -v '/dev/tap32'

*****  Plugin leaks (5.62 confidence) suggests  ******************************

If you want to ignore qemu-kvm trying to read write access the tap32 chr_file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/qemu-kvm /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (1.35 confidence) suggests  ***************************

If you believe that qemu-kvm should be allowed read write access on the tap32 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep qemu-kvm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:svirt_t:s0:c158,c381
Target Context                system_u:object_r:device_t:s0
Target Objects                /dev/tap32 [ chr_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          srv08.kola.fad.ru
Source RPM Packages           qemu-system-x86-1.0.1-2.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-161.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     srv08.kola.fad.ru
Platform                      Linux srv08.kola.fad.ru 3.6.7-4.fc17.x86_64 #1 SMP
                              Tue Nov 20 19:40:01 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    2012-11-30 18:01:45 MSK
Last Seen                     2012-11-30 18:01:45 MSK
Local ID                      8ae6cfcf-c399-4029-ae0a-e82fb43655aa

Raw Audit Messages
type=AVC msg=audit(1354284105.34:2435): avc:  denied  { read write } for  pid=14415 comm="qemu-kvm" path="/dev/tap32" dev="devtmpfs" ino=487270 scontext=system_u:system_r:svirt_t:s0:c158,c381 tcontext=system_u:object_r:device_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1354284105.34:2435): arch=x86_64 syscall=execve success=yes exit=0 a0=7f96840de380 a1=7f96840de610 a2=7f96840ddcc0 a3=0 items=0 ppid=1 pid=14415 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:c158,c381 key=(null)

Hash: qemu-kvm,svirt_t,device_t,chr_file,read,write

audit2allow

#============= svirt_t ==============
allow svirt_t device_t:chr_file { read write };

audit2allow -R

#============= svirt_t ==============
allow svirt_t device_t:chr_file { read write };

How reproducible:
Always.

Steps to Reproduce:
1. Start virt-viewer and create new virtual machine.
2. Set Virtual Network Interface:
  Source: Host device p5p1
  Device model: Hypervisor default
  Source mode: Privte
3. Power on the virtual machine.

Additional info:
$ ls -lZ /dev/tap*
crw-------. root root system_u:object_r:tun_tap_device_t:s0 /dev/tap32

Comment 1 Daniel Walsh 2012-11-30 18:51:38 UTC
Did anything actually break or did it all work other then the ugly AVC?

Comment 2 ryanm 2012-12-06 02:49:20 UTC
I just ran into this bug today.  It breaks macvtap in bridge mode on qemu-kvm guests.

/var/log/audit/audit.log:
type=AVC msg=audit(1354758128.155:86238): avc:  denied  { read write } for  pid=15463 comm="qemu-kvm" path="/dev/tap10" dev=devtmpfs ino=53412 scontext=system_u:system_r:svirt_t:s0:c149,c702 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

/var/log/libvirt/qemu/virttest.log:
qemu-kvm: -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23: TUNGETIFF ioctl() failed: Bad file descriptor
TUNSETOFFLOAD ioctl() failed: Bad file descriptor
unable to start vhost net: 88: falling back on userspace virtio

Comment 3 Charlie Brady 2012-12-10 17:06:29 UTC
See also bug 825942.

Comment 4 Fedora End Of Life 2013-07-04 00:53:54 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 '17'.

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 17'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 17 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, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

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.

Comment 5 Miroslav Grepl 2013-07-07 07:18:29 UTC

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