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
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?
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
*** Bug 1139833 has been marked as a duplicate of this bug. ***
With 1.2.8 installed and after a reboot, things are back to normal for me. Thanks!
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
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
*** Bug 1140426 has been marked as a duplicate of this bug. ***
I've proposed patch upstream: https://www.redhat.com/archives/libvir-list/2014-September/msg01163.html
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
The patch in comment #8 is in fedora, so closing this, but there are additional issues being tracked in bug 1147057