Description of problem: More virt-manager /dev/net/tun stuff; I think this one happens when I run two VMs at once. SELinux is preventing /usr/bin/qemu-system-x86_64;5424e9e4 (deleted) from 'ioctl' accesses on the chr_file /dev/net/tun. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that qemu-system-x86_64;5424e9e4 (deleted) 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:c663,c669 Target Context system_u:object_r:tun_tap_device_t:s0:c155,c1021 Target Objects /dev/net/tun [ chr_file ] Source qemu-system-x86 Source Path /usr/bin/qemu-system-x86_64;5424e9e4 (deleted) Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-82.fc21.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.17.0-0.rc5.git5.2.fc22.1.x86_64 #1 SMP Fri Sep 19 20:35:24 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-09-26 10:47:29 PDT Last Seen 2014-09-26 10:47:29 PDT Local ID e52078ab-713d-456f-93cf-39a2d3a91653 Raw Audit Messages type=AVC msg=audit(1411753649.89:8982): avc: denied { ioctl } for pid=7865 comm="qemu-system-x86" path="/dev/net/tun" dev="devtmpfs" ino=14343 scontext=system_u:system_r:svirt_t:s0:c663,c669 tcontext=system_u:object_r:tun_tap_device_t:s0:c155,c1021 tclass=chr_file permissive=0 type=SYSCALL msg=audit(1411753649.89:8982): arch=x86_64 syscall=ioctl success=no exit=EACCES a0=1b a1=400454d0 a2=f a3=0 items=0 ppid=1 pid=7865 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=2F7573722F62696E2F71656D752D73797374656D2D7838365F36343B3534323465396534202864656C6574656429 subj=system_u:system_r:svirt_t:s0:c663,c669 key=(null) Hash: qemu-system-x86,svirt_t,tun_tap_device_t,chr_file,ioctl Version-Release number of selected component: selinux-policy-3.13.1-82.fc21.noarch Additional info: reporter: libreport-2.2.3 hashmarkername: setroubleshoot kernel: 3.17.0-0.rc5.git5.2.fc22.1.x86_64 type: libreport
Description of problem: attempted to create a new box in gnome-boxes, got this selinux warning Version-Release number of selected component: selinux-policy-3.13.1-82.fc21.noarch Additional info: reporter: libreport-2.2.3 hashmarkername: setroubleshoot kernel: 3.16.3-300.fc21.x86_64 type: libreport
Description of problem: started a virtual machine, setroubleshoot warns of issues the virtual machine can't access the network Version-Release number of selected component: selinux-policy-3.13.1-82.fc21.noarch Additional info: reporter: libreport-2.2.3 hashmarkername: setroubleshoot kernel: 3.16.3-300.fc21.x86_64 type: libreport
Description of problem: Started a VM via virt-manager that has a NIC configured to connect via a bridge adapter. Version-Release number of selected component: selinux-policy-3.13.1-84.fc21.noarch Additional info: reporter: libreport-2.2.3 hashmarkername: setroubleshoot kernel: 3.16.3-302.fc21.x86_64 type: libreport
*** Bug 1146320 has been marked as a duplicate of this bug. ***
The problem is the tun_tap_device_t has MCS assigned.
*** Bug 1149600 has been marked as a duplicate of this bug. ***
Patch proposed upstream: https://www.redhat.com/archives/libvir-list/2014-October/msg00228.html
*** Bug 1016326 has been marked as a duplicate of this bug. ***
*** Bug 1144482 has been marked as a duplicate of this bug. ***
*** Bug 1146859 has been marked as a duplicate of this bug. ***
*** Bug 1149500 has been marked as a duplicate of this bug. ***
Is there any workaround I can use until the problem is fixed ? It is blocking my work with multiple VMs, as one gets access to the network and all others don't.
(In reply to Simo Sorce from comment #12) > Is there any workaround I can use until the problem is fixed ? > It is blocking my work with multiple VMs, as one gets access to the network > and all others don't. I'd say the only workaround is disabling SELinux driver in libvirt completely. security_driver = "" in qemu.conf.
However, I've pushed the patch upstream: commit ebc05263960f41065fa7d882959ea754b9281ab1 Author: Michal Privoznik <mprivozn> AuthorDate: Tue Oct 7 16:22:17 2014 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Wed Oct 8 15:15:58 2014 +0200 security_selinux: Don't relabel /dev/net/tun https://bugzilla.redhat.com/show_bug.cgi?id=1147057 The code for relabelling the TAP FD is there due to a race. When libvirt creates a /dev/tapN device it's labeled as 'system_u:object_r:device_t:s0' by default. Later, when udev/systemd reacts to this device, it's relabelled to the expected label 'system_u:object_r:tun_tap_device_t:s0'. Hence, we have a code that relabels the device, to cut the race down. For more info see ae368ebfcc4. But the problem is, the relabel function is called on all TUN/TAP devices. Yes, on /dev/net/tun too. This is however a special kind of device - other processes uses it too. We shouldn't touch it's label then. Ideally, there would an API in SELinux that would label just the passed FD and not the underlying path. That way, we wouldn't need to care as we would be not labeling /dev/net/tun but the FD passed to the domain. Unfortunately, there's no such API so we have to workaround until then. Tested-by: Richard W.M. Jones <rjones> Signed-off-by: Michal Privoznik <mprivozn>
libvirt-1.2.9-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libvirt-1.2.9-3.fc21
Michal, I did one more look and see we had AVCs related to /dev/net/tun. Just found the libvirt should create /dev/net/tunX for which we could have MCS label? Am i wrong with /dev/net/tunX?
Package libvirt-1.2.9-3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.2.9-3.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12639/libvirt-1.2.9-3.fc21 then log in and leave karma (feedback).
libvirt-1.2.9-3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Miroslav Grepl from comment #16) > Michal, > I did one more look and see we had AVCs related to /dev/net/tun. Just found > the libvirt should create /dev/net/tunX for which we could have MCS label? > Am i wrong with /dev/net/tunX? Well, there's no reason to make libvirt create /dev/net/tunX. The way that tun/tap devices work is that open()-ing them creates you a tap device that can be managed by the usual network tools (e.g. they can be plugged into a bridge). Moreover, the open() will give you a FD to which you can send/receive from data. Enforcing libvirt to create a /dev/net/tunX per domain is just workarounding missing SELinux API. And remember, it's not only libvirt that would need to do that. There are other application - like vpnc - that create TUN devices. They would need to implement the same workaround. We should do the right thing and introduce the SELinux API that would label just the passed FD and not the underlying path. Honestly, I wonder why there's no such API yet.
(In reply to Michal Privoznik from comment #19) > (In reply to Miroslav Grepl from comment #16) > > Michal, > > I did one more look and see we had AVCs related to /dev/net/tun. Just found > > the libvirt should create /dev/net/tunX for which we could have MCS label? > > Am i wrong with /dev/net/tunX? > > Well, there's no reason to make libvirt create /dev/net/tunX. The way that > tun/tap devices work is that open()-ing them creates you a tap device that > can be managed by the usual network tools (e.g. they can be plugged into a > bridge). Moreover, the open() will give you a FD to which you can > send/receive from data. Enforcing libvirt to create a /dev/net/tunX per > domain is just workarounding missing SELinux API. And remember, it's not > only libvirt that would need to do that. There are other application - like > vpnc - that create TUN devices. They would need to implement the same > workaround. We should do the right thing and introduce the SELinux API that > would label just the passed FD and not the underlying path. Honestly, I > wonder why there's no such API yet. Well I don't think it is so easy just label passed FD. CC-ing pmoore.
(In reply to Miroslav Grepl from comment #20) > (In reply to Michal Privoznik from comment #19) > > (In reply to Miroslav Grepl from comment #16) > > > Michal, > > > I did one more look and see we had AVCs related to /dev/net/tun. Just found > > > the libvirt should create /dev/net/tunX for which we could have MCS label? > > > Am i wrong with /dev/net/tunX? > > > > Well, there's no reason to make libvirt create /dev/net/tunX. The way that > > tun/tap devices work is that open()-ing them creates you a tap device that > > can be managed by the usual network tools (e.g. they can be plugged into a > > bridge). Moreover, the open() will give you a FD to which you can > > send/receive from data. Enforcing libvirt to create a /dev/net/tunX per > > domain is just workarounding missing SELinux API. And remember, it's not > > only libvirt that would need to do that. There are other application - like > > vpnc - that create TUN devices. They would need to implement the same > > workaround. We should do the right thing and introduce the SELinux API that > > would label just the passed FD and not the underlying path. Honestly, I > > wonder why there's no such API yet. > > Well I don't think it is so easy just label passed FD. CC-ing pmoore. Why not? SELinux is already able to do that. I mean, it would require the kernel to cache the labels as they can't be stored in the XATTRs, but this is already implemented. For instance calling fsetfilecon() over an FD that is a pipe will label the FD only. The reason why I'm so demanding for the API is, that it would be future proof. One of the aims is, that libvirt will (in not so distant future and in this galaxy) open all the files for qemu and then just pass the FDs. However, currently it's not possible for all the resources, so for instance on disks, libvirt actually needs to touch the selinux label defined on the file. And then, when the domain is shut down and libvirt does the cleanup, the best what we can do is 'restorecon $file'. However, if the API would label only the FD, we would not need to even bother. Moreover, there are some files we rather not re-label that we do open and pass to qemu currently: pci config files. Anyway, lets see what Paul thinks.
While sockets do have associated file descriptors they are not, they behave very differently from files. Because of the differences relabeling sockets once they are created is not allowed, and never will be, as it could result in the relabeling of data that has already been "sent" under a different label.