Re: [PATCH] test: Update README.md

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

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

> 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. Only the
spawned QEMU could be confined strictly, and that would be equiv to
what is already done with libvirt's policy for QEMU.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|