On Thu, Nov 03, 2022 at 12:35:15PM -0400, Andrea Bolognani wrote: > 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. I don't see how this can work properly. If running with AppArmor, I would expect libvirtd itself needs to be built with AppArmor, so that when launching a VM it can spawn virt-aa-helper to create the per-VM customized profile. The CentOS based libvirt running inside the container will be built without virt-aa-helper, so won't load this. I would rather expect that AppArmor does not attempt to control any processes inside the containers, other than with a generic 'docker' AppArmor profile. It makes no sense for profiles from the host OS install to apply to stuff in containers, as we can't assume the host + container installs are the same versions. Are you sure the KubeVirt problem isn't simply a mis-configuration of the host environment allowing AppArmor to leak inside the container. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
