On Thu, 13 Feb 2025 09:16:33 +0100
Christian Ehrhardt <christian.ehrhardt(a)canonical.com> wrote:
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 :-/
So, about passt, the compromise we now have upstream (Debian packages
coming in a bit) is probably the quickest way to restore functionality,
but it's also the most... compromising, because passt isn't necessarily
started by libvirt, and yet it's now going to allow read-write access to
@{run}/user/[0-9]*/libvirt/qemu/run/passt/*, libvirt or not, and to
execute itself.
The compromise described below would avoid this, while being reasonably
simple.
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.
...and, by the way, at least nothing is running as root with that
profile.
In this case, a strong isolation between users is already provided even
without AppArmor. We just wouldn't isolate between VMs run by the same
user.
> 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...
--
Stefano