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

[Michal Privoznik]

On 18.09.2014 18:36, John Ferlan wrote:
>
>
> 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 at redhat.com>
>> ---
>>   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
>

Okay, I've fixed the commit message and pushed. Thanks!

Michal