Re: [libvirt] [PATCH] virSecuritySELinuxSetTapFDLabel: Temporarily revert to old behavior

On 09/18/2014 10:20 AM, Michal Privoznik wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1141879 > > A long time ago I've implemented support for so called multiqueue > net. The idea was to let guest network traffic be processed by > multiple host CPUs and thus increasing performance. However, this > behavior is enabled by QEMU via special ioctl() iterated over the > all tap FDs passed in by libvirt. Unfortunately, SELinux comes in > and disallows the ioctl() call because the /dev/net/tun has label > system_u:object_r:tun_tap_device_t:s0 and 'attach_queue' ioctl() > is not allowed on tun_tap_device_t type. So after discussion with > a SELinux developer we've decided that the FDs passed to the QEMU > should be labelled with svirt_t type and SELinux policy will > allow the ioctl(). Therefore I've made a patch > (cf976d9dcf4e592261b14f03572) that does exactly this. However, > things are not that easy - even though the API to label FD is > called (fsetfilecon_raw) the underlying file is labelled too! So > effectively we are mangling /dev/net/tun label. Yes, that broke > dozen of other application from openvpn, or boxes, to qemu > running other domains. > > The best solution would be if SELinux provides a way to label an > FD only, which could be then labeled when passed to the qemu. > However that's a long path to go and we should fix this > regression AQAP. So I went to talk to the SELinux developer again > and we agreed on temporary solution that: > > 1) my patch is reverted > 2) SELinux temporarily allows 'attach_queue' on the > tun_tap_device_t > > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > --- > src/security/security_selinux.c | 36 +++++++++++++++++++++++++++++++++--- > 1 file changed, 33 insertions(+), 3 deletions(-) > Probably should note that this also reverts a4431931393aeb1ac5893f121151fa3df4fde612 (in 1.2.8) and b635b7a1af0e64754016d758376f382470bc11e7 (post 1.2.8) Although neither really matters with this change - it just points out the trail for the "secdef->imagelabel -> secdef->label" change that isn't present in cf976d... ACK John