Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1139646 - SELinux is preventing /usr/bin/qemu-system-x86_64 from 'ioctl' accesses on the chr_file /dev/net/tun.
Summary: SELinux is preventing /usr/bin/qemu-system-x86_64 from 'ioctl' accesses on th...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 21
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Privoznik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:59838b67134e7277a6aa9645e72...
: 1139833 1140426 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-09 11:29 UTC by Nils Philippsen
Modified: 2014-10-07 15:35 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-07 15:35:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1095636 0 high CLOSED SELinux prevent qemu from attaching tuntap queues 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1140426 0 unspecified CLOSED SELinux is preventing /usr/sbin/openvpn from read, write access on the chr_file tun. 2021-02-22 00:41:40 UTC

Internal Links: 1095636 1140426

Description Nils Philippsen 2014-09-09 11:29:51 UTC
Description of problem:
Started two VMs using virt-manager.
SELinux is preventing /usr/bin/qemu-system-x86_64 from 'ioctl' accesses on the chr_file /dev/net/tun.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that qemu-system-x86_64 should be allowed ioctl access on the tun 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-system-x86 /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:svirt_t:s0:c792,c949
Target Context                system_u:object_r:svirt_image_t:s0:c31,c281
Target Objects                /dev/net/tun [ chr_file ]
Source                        qemu-system-x86
Source Path                   /usr/bin/qemu-system-x86_64
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.16.2-300.fc21.x86_64 #1 SMP Sat
                              Sep 6 02:51:08 UTC 2014 x86_64 x86_64
Alert Count                   1
First Seen                    2014-09-09 13:26:52 CEST
Last Seen                     2014-09-09 13:26:52 CEST
Local ID                      0b287afb-66fa-43d0-a3cb-912304bef77b

Raw Audit Messages
type=AVC msg=audit(1410262012.244:622): avc:  denied  { ioctl } for  pid=26842 comm="qemu-system-x86" path="/dev/net/tun" dev="devtmpfs" ino=9247 scontext=system_u:system_r:svirt_t:s0:c792,c949 tcontext=system_u:object_r:svirt_image_t:s0:c31,c281 tclass=chr_file permissive=0


type=SYSCALL msg=audit(1410262012.244:622): arch=x86_64 syscall=ioctl success=no exit=EACCES a0=18 a1=400454d0 a2=f a3=0 items=0 ppid=1 pid=26842 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm=qemu-system-x86 exe=/usr/bin/qemu-system-x86_64 subj=system_u:system_r:svirt_t:s0:c792,c949 key=(null)

Hash: qemu-system-x86,svirt_t,svirt_image_t,chr_file,ioctl

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.16.2-300.fc21.x86_64
type:           libreport

Comment 1 Michal Privoznik 2014-09-09 16:27:24 UTC
I think this is fixed upstream by these commits:

commit a4431931393aeb1ac5893f121151fa3df4fde612
Author:     Martin Kletzander <mkletzan>
AuthorDate: Mon Sep 1 15:27:00 2014 +0200
Commit:     Martin Kletzander <mkletzan>
CommitDate: Mon Sep 1 15:36:23 2014 +0200

    selinux: properly label tap FDs with imagelabel
    
    The cleanup in commit cf976d9d used secdef->label to label the tap
    FDs, but that is not possible since it's process-only label (svirt_t)
    and not a object label (e.g. svirt_image_t).  Starting a domain failed
    with EPERM, but simply using secdef->imagelabel instead of
    secdef->label fixes it.
    
    Signed-off-by: Martin Kletzander <mkletzan>

commit cf976d9dcf4e592261b14f03572bb519531ebbce
Author:     Michal Privoznik <mprivozn>
AuthorDate: Wed Aug 13 16:08:03 2014 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Wed Aug 20 09:42:24 2014 +0200

    qemu: Label all TAP FDs
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1095636
    
    When starting up the domain the domain's NICs are allocated. As of
    1f24f682 (v1.0.6) we are able to use multiqueue feature on virtio
    NICs. It breaks network processing into multiple queues which can be
    processed in parallel by different host CPUs. The queues are, however,
    created by opening /dev/net/tun several times. Unfortunately, only the
    first FD in the row is labelled so when turning the multiqueue feature
    on in the guest, qemu will get AVC denial. Make sure we label all the
    FDs needed.
    
    Moreover, the default label of /dev/net/tun doesn't allow
    attaching a queue:
    
        type=AVC msg=audit(1399622478.790:893): avc:  denied  { attach_queue }
        for  pid=7585 comm="qemu-kvm"
        scontext=system_u:system_r:svirt_t:s0:c638,c877
        tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023
        tclass=tun_socket
    
    And as suggested by SELinux maintainers, the tun FD should be labeled
    as svirt_t. Therefore, we don't need to adjust any range (as done
    previously by Guannan in ae368ebf) rather set the seclabel of the
    domain directly.
    
    Signed-off-by: Michal Privoznik <mprivozn>


They are both contained in the 1.2.8 release.
Nils, can you update the libvirt and re-run?

Comment 2 Adam Williamson 2014-09-10 00:52:12 UTC
Description of problem:
Happens on booting a VM on a libvirt NAT network.

Version-Release number of selected component:
selinux-policy-3.13.1-78.fc21.noarch

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.17.0-0.rc3.git2.2.fc22.1.x86_64
type:           libreport

Comment 3 Miroslav Grepl 2014-09-10 10:21:26 UTC
*** Bug 1139833 has been marked as a duplicate of this bug. ***

Comment 4 Nils Philippsen 2014-09-10 11:46:37 UTC
With 1.2.8 installed and after a reboot, things are back to normal for me. Thanks!

Comment 5 Fedora Update System 2014-09-10 13:25:52 UTC
libvirt-python-1.2.8-1.fc21, libvirt-1.2.8-1.fc21, perl-Sys-Virt-1.2.8-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/FEDORA-2014-10270/libvirt-python-1.2.8-1.fc21,libvirt-1.2.8-1.fc21,perl-Sys-Virt-1.2.8-1.fc21

Comment 6 Adam Williamson 2014-09-11 00:28:38 UTC
well, libvirt isn't the only thing that touches /dev/net/tun , apparently. After this update, openvpn stops working:

https://bugzilla.redhat.com/show_bug.cgi?id=1140426

Comment 7 Miroslav Grepl 2014-09-15 08:54:14 UTC
*** Bug 1140426 has been marked as a duplicate of this bug. ***

Comment 8 Michal Privoznik 2014-09-18 14:23:47 UTC
I've proposed patch upstream:


https://www.redhat.com/archives/libvir-list/2014-September/msg01163.html

Comment 9 Jared Smith 2014-09-26 09:09:46 UTC
Description of problem:
Attempting to connect to an OpenVPN VPN

Version-Release number of selected component:
selinux-policy-3.13.1-79.fc21.noarch

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.16.3-300.fc21.x86_64
type:           libreport

Comment 10 Cole Robinson 2014-10-07 15:35:17 UTC
The patch in comment #8 is in fedora, so closing this, but there are additional issues being tracked in bug 1147057


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