Re: AppArmor confinement for qemu:///session VMs
On Wed, Feb 5, 2025 at 6:22 PM Andrea Bolognani <abologna(a)redhat.com> wrote:
An issue was recently reported[1] with running unprivileged VMs
configured to use passt on Debian with AppArmor confinement enabled.
Hi Andrea (and Stefano),
thank you for the depth and work on the topic!
After looking into the situation, I am convinced that AppArmor
confinement never really worked for unprivileged VMs. The whole
mechanism is built around the concept of per-VM profiles that are
dynamically generated and registered, but doing so requires write
access to /etc/apparmor.d/ and in general permissions that
unprivileged libvirt will by design not have.
It becomes clear that, while it works well for the use cases that existed
when Jaimie was developing it, it no longer does so for many modern
approaches. From recent discussions about hotplug [1] to older
demands to better handle pools [2] and various in-betweens - they
all tend to come to a compromise or big-rework approach.
So unless/until there is a major spike to rework the apparmor/libvirt
interaction we have to make compromises like the one you went
for below :-/
For the time being I think we should be ok with (non-too awkward)
compromise solutions. While it reduces the pain that would force
to do the big rework, it keeps users functional and that is what we
should care about the most.
I'm even tempted to suggest accepting [1] without insisting on too
big of a rework for the same reasons.
FWIW I've added the unprivileged user session handling to my list
of known "one should do for apparmor/libvirt ..." tracking list.
[1]: https://gitlab.com/libvirt/libvirt/-/issues/692
[2]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398
Of course it's unfortunate that unprivileged VMs would be forced
to
miss out on the potential benefits of AppArmor isolation, and even
more unfortunate that passt won't work out of the box for
unprivileged VMs, since those are the ones where it makes the most
sense to use passt in the first place.
Stefano suggested introducing a generic "libvirt-user" profile that
would be attached to unprivileged VMs and would be more liberal than
the one used for privileged VMs, since we wouldn't be able to tailor
it to the specifics of the VM, but would at least prevent the worst
of the abuse; specifically, it would only allow R/W access to files
in the current user's home directory.
Does that sound like a reasonable direction? Any other ideas?
I've read it probably the fourth time now, each time before concluding
"I need to think more, maybe something comes to mind if I don't read
in a rush" :-)
But even after the fourth time I like the compromise that you proposed.
It is much better than not isolating them at all, after all libvirtd itself
also has a liberal profile and despite being so "open" has prevented
quite some already.
In the meantime, Stefano has posted a workaround[2] that, when
applied to passt's AppArmor profile, would allow these VMs to at
least start.
CC'ing people with AppArmor knowledge for awareness.
[1] https://archives.passt.top/passt-dev/20250129104112.0756df5c@elisabeth/T/#u
[2]
https://archives.passt.top/passt-dev/20250205163101.3793658-1-sbrivio@red...
--
Andrea Bolognani / Red Hat / Virtualization
--
Christian Ehrhardt
Director of Engineering, Ubuntu Server
Canonical Ltd