On Wed, Feb 5, 2025 at 6:22 PM Andrea Bolognani <abologna@xxxxxxxxxx> 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@xxxxxxxxxx/T/#u > -- > Andrea Bolognani / Red Hat / Virtualization > -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
