[libvirt PATCH] apparmor: Allow running /usr/libexec/qemu-kvm

[Andrea Bolognani]

On Thu, Nov 03, 2022 at 03:39:44PM +0100, Peter Krempa wrote:
> On Thu, Nov 03, 2022 at 12:13:53 +0100, Andrea Bolognani wrote:
> > Distros that use AppArmor, such as Debian and Ubuntu, install
> > QEMU under /usr/bin/qemu-system-*, and our AppArmor profile is
> > written with that assumption in mind.
> >
> > If you try to run the RHEL or CentOS version of libvirt and
> > QEMU inside a privileged container on such distros, however,
> > that will result in an error, because the path
> > /usr/libexec/qemu-kvm is used instead.
>
> So IIUC by this patch you modify the profile which gets installed into
> the Debian/Ubuntu host system by the Debian/Ubuntu package which then in
> turn allows the non-Debian/Ubuntu libvirt in the container to do it's
> job?

Pretty much.

> I'm basing the above on the fact that the RHEL/Centos package is
> compiled with:
>
>            -Dapparmor=disabled \
>            -Dapparmor_profiles=disabled \
>            -Dsecdriver_apparmor=disabled \
>
> By extension, does that mean that you have to install libvirt on your
> host so that you can in turn run a container (which I'd presume is
> opaque) with libvirt bundled inside?

It's actually the other way around :)

If you don't have libvirt installed on the Debian/Ubuntu host, then
the AppArmor profile won't be present and the containerized CentOS
libvirt will be allowed to start the containerized CentOS QEMU.

If you *do* have libvirt installed on the Debian/Ubuntu host, then
the AppArmor profile will also be applied to the containerized CentOS
libvirt and running the containerized CentOS QEMU will be forbidden.

Patching the AppArmor policy is supposed to help with the second
scenario.


Please check out the discussion at

  https://github.com/kubevirt/kubevirt/pull/8692

if you haven't already, it's not very long and might help clear
things up :)

-- 
Andrea Bolognani / Red Hat / Virtualization