Re: Apparmor (and other) Issues

[Andrea Bolognani <abologna@redhat.com>]

On Tue, Feb 04, 2025 at 08:14:48PM +0100, Stefano Brivio wrote:
> On Tue, 4 Feb 2025 18:46:37 +0000 Andrea Bolognani <abologna@redhat.com> wrote:
> > > 2. (most reasonable I think) don't use per-VM profiles for the rootless
> > >    case. Define a single "libvirt-user" (or "libvirt-session") profile
> > >    and use that. We could copy it from the existing ones I suppose.
> >
> > Sounds to me like this would require granting the QEMU process access
> > to roughly the entire filesystem? The disk image could live anywhere
> > after all, and if we can't dynamically add a rule for the exact path
> > the only way out is a free-for-all approach.
>
> Right. That's what we did for libguestfs as well, the image can be
> *almost* anywhere. But it's not free-for-all: you're just granting
> *limited* filesystem access (not to sysfs, not to /etc, and so on).
>
> And I had to build a *very* loose profile for libguestfs because that
> applies to root as well, but for rootless libvirtd, it might even make
> sense to restrict access to just @{HOME}/** and /tmp/** (that's what I
> did for stand-alone passt, for example).

That could work, I suppose. Needs to be discussed upstream, making
sure to involve those who are more experienced with AppArmor than I
am, especially since it's not just a matter of updating the policy
but fundamentally changing how the driver works when operating in
unprivileged mode.

> I'll try to submit a pull request at least for Debian in a couple of
> days.

Be aware that I will emphatically refuse to introduce changes to the
Debian package unless they have been merged upstream first. AppArmor
support lives in the upstream repository, and all fixes and
improvements have to go through it.

-- 
Andrea Bolognani / Red Hat / Virtualization