Re: [PATCH] test: Update README.md

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 24 Sep 2025 12:20:03 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Wed, Sep 24, 2025 at 01:05:53PM +0200, Stefano Brivio wrote:
> > On Wed, 24 Sep 2025 11:31:31 +0100
> > "Richard W.M. Jones" <rjones@redhat.com> wrote:
> >   
> > > On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:  
> > > > And now that you say that, I just realised that it would be as simple
> > > > as:
> > > > 
> > > >   https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-libguestfs-as-root
> > > > 
> > > >   LIBGUESTFS_BACKEND=direct virt-edit...    
> > > 
> > > While that will indeed work, we're trying to discourage people from
> > > doing that, since it removes the other good things that libvirt does,
> > > such as setting up SELinux.  
> > 
> > Oh, I see. I guess it makes sense, with a number of caveats:
> > 
> > 1. libvirt's SELinux policy doesn't seem to be really maintainable /
> >    long-term sustainable to me, especially because it's still part of
> >    fedora-selinux  
> 
> Well it isn't ideal that Fedora policy is largely centralized, but
> it has been maintained it since 2007, so claiming it is not long
> term sustainable is just FUD.

I'd rather call it observation. We're just piling up workarounds
because merge requests are not really evaluated or accepted, for
example https://github.com/fedora-selinux/selinux-policy/pull/1613.
Your own comment to it:

  https://github.com/fedora-selinux/selinux-policy/pull/1613#issuecomment-1467759276

perfectly explains one of the biggest maintainability concerns I
have, because not being able to use interfaces as designed leads to
issues such as:

  https://github.com/fedora-selinux/selinux-policy/issues/2579

for which, again, I could propose a simple change, but I don't
exactly have confidence that it will be considered. That leads in turn
to more workarounds, say:

  https://passt.top/passt/commit/?id=87471731e6bb0b5df3a50277527caf3381b45ee4
  https://passt.top/passt/commit/?id=98d474c8950e9cc5715d5686614fb0f504377303

I don't understand how the fact that it's been like that since 2007
would suggest a positive or negative correlation to maintainability.

Things keeps breaking and I keep adding more workarounds, not fixes.
You can go ahead and blame me for that, but I was talking about how *I*
perceive maintainability. Again:

> 1. libvirt's SELinux policy doesn't seem to be really maintainable /
>    long-term sustainable to me
                              ^^

...we probably have different concepts of it. That doesn't make it FUD.

> > 2. it adds a rather artificial dependency on libvirt, so in the end
> >    you're running more things, and more complicated ones, even if it's
> >    not needed  
> 
> Libvirt provides a stable interface to interacting with QEMU
> over decades. QEMU's own interface is only guaranteed stable
> over 2 releases.  As QEMU changes its interface and/or best
> practice configuration approach, libvirt adapts to this so
> every app doesn't have to repeat this work.

It depends on the use case. For the use case at hand, we would be
absolutely fine with things breaking every six months, or even more
frequently.

> > 3. the profile is still much looser than what a libguestfs specific
> >    profile could be, see for example the AppArmor policy I introduced
> >    at:
> > 
> >      https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a6621d0b61907f9269a2506680684f
> > 
> >    which, despite being rather loose, is still arguably much stricter
> >    than this beast (and related add-ons):
> > 
> >      https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.sbin.libvirtd.in
> > 
> >    and I think a strict subset of it, as well.  
> 
> This is the policy for the libvirt daemon, which is separate from the
> policy that the QEMU guest runs under - the latter is constrained to
> limit access to resources configured for the guest VM.
> 
> The libvirt daemon policy needs to be loose by default, since users
> want libvirt to be able to access a wide range of files and resources.
> This same need applies to guestfish - it needs to access arbitrarily
> specified disk images, so would need a very loose policy.

About disk images, of course, that's what I added for libguestfs:

  /** mrwlk

and that's the same in libvirt's AppArmor policy.

The set of permitted capabilities is very different, though, and
libguestfs doesn't of course need all those helpers or, say, the
ability to mount /dev, which, with AppArmor, can't be qualified /
limited much further than that.

> Only the
> spawned QEMU could be confined strictly, and that would be equiv to
> what is already done with libvirt's policy for QEMU.

...see links above? Those are not equivalent.

-- 
Stefano