Re: [PATCH RFC] qga: Add selinux-helper for guest-exec subcommand (bsc#1237450)

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

On Tue, Apr 14, 2026 at 06:51:12PM +0200, Martin Wilck wrote:
> On Fri, 2026-03-27 at 14:33 +0000, Daniel P. Berrangé wrote:
> > On Fri, Mar 27, 2026 at 11:25:19AM +0100, Cathy Hu wrote:
> > > From: Cathy Hu <cahu@suse.de>
> > > 
> > > Problem:
> > > 
> > > ATM the QEMU Guest Agent and SELinux are not working together
> > > properly.
> > > The fedora (and therefor also the openSUSE) policy confine the
> > > qemu-guest-agent
> > > service in the domain `qemu_ga_t`. That means, qemu-guest-agent
> > > is only allowed to do what the policy says.
> > > 
> > > However, the `guest-exec` command allows arbitrary execution
> > > of code from a privileged service, which conflicts with the
> > > notion of SELinux confinement.
> > > 
> > > ATM, the policy allows only some accesses that are used
> > > by other qemu-guest-agent commands.
> > > That means, the qemu-guest-agent fails sporadically, depending
> > > on what is allowed for other commands.
> > > However, `guest-exec` would need to allow everything.
> > > 
> > > see https://bugzilla.suse.com/show_bug.cgi?id=1237450
> > > 
> > > Solution:
> > > 
> > > This is not an great solution, but it works like this:
> > > We add a "wrapper" which is executed instead of the program
> > > that is called via `guest-exec`. The "wrapper" just
> > > re-executes the command given by `guest-exec`.
> > > This way, on the SELinux policy side we can give that
> > > wrapper executable a label on the file system.
> > > With that label, we can transition into a more broader
> > > unconfined domain _and_ toggle that transition with a
> > > SELinux boolean. That would make `guest-exec`
> > > consistently allowed to execute or not by policy.
> > > 
> > > This needs a change on the SELinux policy side to
> > > accompany this with:
> > > https://github.com/fedora-selinux/selinux-policy/pull/3122
> > > 
> > > What other options have been tried unsuccessfully:
> > > 
> > > - Fixing via SELinux policy: It is not possible for
> > >   one domain to have different permissions depending on
> > >   code path. It is also not possible to toggle the permissive
> > >   state via a SELinux boolean, so users would need
> > >   to add it via semanage.
> > > - Setting the domain of the executed commands directly
> > >   to a broader domain with setcon/setexeccon.
> > >   The SELinux kernel does not allow to spawn a process
> > >   directly with those that has broader privileges than the parent.
> > > 
> > > What other options are there to solve this issue:
> > > 
> > > - Making the qemu-guest-agent unconfined by default
> > > - Document the workaround to use semanage to make the domain
> > > permissive
> > >   if `exec-guest` is needed as works as intended and ignore the
> > > problem
> > 
> > IMHO, the 'exec' command should never have been added to the
> > QEMU guest agent, for precisely this reason that it makes it
> > impractical to put any meaningful security controls around it.
> > Likewise the commands which allow arbitrary file read/write.
> > 
> > QEMU guest agent should focus on specific targetted tasks
> > with dedicated commands.
> > 
> > NB: in RHEL we disable all those unconfinable commands.
> 
> Downstream bug reporter here. My use case, for which Cathy has come up
> with the solution proposed, was to be able to run the ansible libvirt
> connection plugin to connect to a freshly installed VM before sshd was
> actually configured on the VM, or on a VM that didn't allow ssh access
> at all.
> 
> My thinking was that the access control was done by libvirt in this
> case. The user running ansible would either need to have access to
> qemu:///system, or to some remote libvirt server via libvirt's access
> controls (in my case, ssh). Users with this permission level would be
> able to pause, hard-reset, or destroy the VM in question, so I was
> thinking that being able to execute arbitrary commands inside the VM
> was not that problematic. But I may be overlooking something, of
> course.

Yes, with traditional virtualization, if you have privileged
access to the host OS, then the guest has no real protection.

None the less in very many scenarios, the VM user broadly
considers the hypervisor admin to be untrusted. Even if the
technology can't enforce protection against a host admin,
the guest doesn't have to open the front door and welcome
them in by opening "guest-exec" command.

With confidential virtualization, the host OS is generally 
not supposed to have any unsecured access to the guest. For
this the intent is to disable the majority of guest agent
commands which would compromise guest confidentiality
by the host.


> > If users want to support an ability to have arbitrary command
> > execution, then that should be done with SSH over VSock, where
> > the guest owner can choose whether to require authentication
> > first or not, and use SSH authorized_keys if desired to limit
> > what commands can be run for a given recorded key.
> > 
> > These days systemd installs magic to allow SSH'ing directly
> > to a guest using VSOCK addresses, and libvirt further
> > enhances that to allow SSH'ing to a named VM.
> 
> Thanks, I wasn't aware of this feature so far. I suppose you're
> referring to https://libvirt.org/ssh-proxy.html. I'll need to
> experiment with it. IIUC this works for local libvirt connections only?

Yes, vsock is exposed to the local host.

> If that's the case, it wouldn't be a full replacement for qemu-agent
> based access, which I've found to be particularly handy for remote
> libvirt instances.

Since libvirt doesn't expose guest-execu either, I presume you're
referring to libvirt's support for agent command passthrough.

One alternative for off-node secure access is to use SSH + socat
to access the vsock channel.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|