Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Tue, 4 Feb 2025 14:19:34 -0800
Andrea Bolognani <abologna@redhat.com> wrote:

> 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

Sure, that makes sense of course.

> especially since it's not just a matter of updating the policy
> but fundamentally changing how the driver works when operating in
> unprivileged mode.

Well, right now it runs unconfined, and (at least with passt) networking
doesn't work. Pretty much any change would be good. :)

I've been disabling AppArmor when I start guests for quite a while now,
thinking that I just broke something on my setup while developing
stuff (I reported that to you but I wasn't sure how the whole thing
worked...). Oops.

> > 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.

Then never mind. I can help filing a Debian issue if needed, let me
know. Or let me know how I can help otherwise.

I would consider a workaround for passt for the moment, say, the whole
block:

    /usr/bin/passt r,

    signal (receive) set=("term") peer=/usr/sbin/libvirtd,
    signal (receive) set=("term") peer=libvirtd,
    signal (receive) set=("term") peer=virtqemud,

    owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw,
    owner @{run}/libvirt/qemu/passt/* rw,

as part of the profile for usr.bin.passt. If you don't see issues with
it, I'll go ahead with that. I still need to check openSUSE though (I
haven't tried for a while there).

-- 
Stefano