[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 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)


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...



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]