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

[Andrea Bolognani]

On Wed, Nov 09, 2022 at 06:14:58PM +0000, Daniel P. Berrangé wrote:
> On Fri, Nov 04, 2022 at 02:56:51PM -0400, Andrea Bolognani wrote:
> > IIUC a specific profile (cri-containerd.apparmor.d) is used for
> > unprivileged containers such as virt-launcher, but a privileged one
> > such as virt-handler falls under the same profile as the host.
> >
> > This makes some amount of sense to me: unprivileged containers are
> > already limited in what they can do by the usual restrictions on user
> > processes. Privileged containers, on the other hand, are effectively
> > root processes, so it's advisable to be significantly more cautious
> > with them.
>
> I still consider that situation to be broken by design. If the
> privileged container is running a completely differnt software
> stack from the host OS, using the host OS apparmour profile
> to confined the container binary is never going to be a reliable
> setup. Either the privileged container has to run without
> confinement, or it needs to be confined using policy provided
> by the container (which is likely not viable anyway).
>
> > Note that this is just my current understanding of the situation, and
> > I'm far from an expert when it comes to containers in general and
> > their interactions with AppArmor in particular. I recommend taking a
> > look at
> >
> >   https://github.com/kubevirt/kubevirt/pull/8692
> >
> > and the issues linked therein, which will provide more context coming
> > from people who actually know what they're talking about :)
>
> I did read that and it didn't give me any more confidence that
> this setup is sensible.

Closing the loop on this one.

After some discussion[1], we have reached the agreement that the
proper way to solve this is to have the node-labeller run in an
unprivileged container, just as the actual VM workload would.

Since doing that requires reworking KubeVirt in non-trivial ways, I
have filed an issue[2] to track this. In the meantime, the user guide
now recommends[3] simply uninstalling libvirt from the host, which is
a simple and effective workaround.

tl;dr SNACK

Thanks everyone for the input!


[1] https://github.com/kubevirt/kubevirt/pull/8692#issuecomment-1305956638
[2] https://github.com/kubevirt/kubevirt/issues/8744
[3] https://github.com/kubevirt/user-guide/pull/618
-- 
Andrea Bolognani / Red Hat / Virtualization