qemu-ga guest-exec & SELinux

qemu-ga guest-exec & SELinux

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Hi!

https://bugzilla.redhat.com/show_bug.cgi?id=2093355 ("AVCs when trying to
execute a command through qemu-ga ("guest-exec" command)") describes an
issue with fedora/rhel SELinux rules, where some program executions are
denied.

qemu-ga has "virt_qemu_ga_t" context, and is not allowed to execute
binaries that are not "bin_t", iiuc. The suggestion from Renaud Métrich is
for qemu-ga exec command to launch the user program through an helper
program that would have the virt_qemu_ga_unconfined_exec_t context, and
appropriate rules in selinux (similar to fsfreeze-hook rules), so any
program can be executed. qemu-ga would thus ship and use that helper, in
all OS, to avoid varying code paths.

Does that sound reasonable or should we try to find a solution with SELinux
rules instead?

thanks

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 1305 bytes --]

Re: qemu-ga guest-exec & SELinux

[Daniel P. Berrangé]

On Mon, Jun 20, 2022 at 01:44:05PM +0400, Marc-André Lureau wrote:
> Hi!
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2093355 ("AVCs when trying to
> execute a command through qemu-ga ("guest-exec" command)") describes an
> issue with fedora/rhel SELinux rules, where some program executions are
> denied.
> 
> qemu-ga has "virt_qemu_ga_t" context, and is not allowed to execute
> binaries that are not "bin_t", iiuc. The suggestion from Renaud Métrich is
> for qemu-ga exec command to launch the user program through an helper
> program that would have the virt_qemu_ga_unconfined_exec_t context, and
> appropriate rules in selinux (similar to fsfreeze-hook rules), so any
> program can be executed. qemu-ga would thus ship and use that helper, in
> all OS, to avoid varying code paths.
> 
> Does that sound reasonable or should we try to find a solution with SELinux
> rules instead?

I thought was did not allow qemu-ga to execute binaries at all, regardless
of whether they're bin_t or not.  The 'guest-exec' command is essentially
a giant hole that defeats the purpose of confining qemu-ga with SELinux
at all IMHO.

IMHO execution of external commands should only be allowed after toggling
a SELinux boolean tunable.


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

Re: qemu-ga guest-exec & SELinux

[Renaud Métrich]

[-- Attachment #1.1: Type: text/plain, Size: 2012 bytes --]

Hi there,

I'm the BZ reporter.

I think the safe solution is to provide something similar to what was 
done for vmtools: have a context switching to become sort of 
"unconfined" domain.

This context switch has to happen only the executor and we already have 
a solution, I documented it in the BZ.

I don't think having an additional boolean is necessary, unless we want 
to restrict the commands the guest can execute.

Note that on RHEL the functionality is disabled by default ("guest-exec" 
is blacklisted), we may add a note in the /etc/sysconfig/qemu-ga file 
stating that allowing such command is risky.

Renaud.

Le 6/20/22 à 12:06, Daniel P. Berrangé a écrit :
> On Mon, Jun 20, 2022 at 01:44:05PM +0400, Marc-André Lureau wrote:
>> Hi!
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2093355 ("AVCs when trying to
>> execute a command through qemu-ga ("guest-exec" command)") describes an
>> issue with fedora/rhel SELinux rules, where some program executions are
>> denied.
>>
>> qemu-ga has "virt_qemu_ga_t" context, and is not allowed to execute
>> binaries that are not "bin_t", iiuc. The suggestion from Renaud Métrich is
>> for qemu-ga exec command to launch the user program through an helper
>> program that would have the virt_qemu_ga_unconfined_exec_t context, and
>> appropriate rules in selinux (similar to fsfreeze-hook rules), so any
>> program can be executed. qemu-ga would thus ship and use that helper, in
>> all OS, to avoid varying code paths.
>>
>> Does that sound reasonable or should we try to find a solution with SELinux
>> rules instead?
> I thought was did not allow qemu-ga to execute binaries at all, regardless
> of whether they're bin_t or not.  The 'guest-exec' command is essentially
> a giant hole that defeats the purpose of confining qemu-ga with SELinux
> at all IMHO.
>
> IMHO execution of external commands should only be allowed after toggling
> a SELinux boolean tunable.
>
>
> With regards,
> Daniel

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: qemu-ga guest-exec & SELinux

[Daniel P. Berrangé]

On Tue, Jun 21, 2022 at 10:42:39AM +0200, Renaud Métrich wrote:
> Hi there,
> 
> I'm the BZ reporter.
> 
> I think the safe solution is to provide something similar to what was done
> for vmtools: have a context switching to become sort of "unconfined" domain.
> 
> This context switch has to happen only the executor and we already have a
> solution, I documented it in the BZ.
> 
> I don't think having an additional boolean is necessary, unless we want to
> restrict the commands the guest can execute.

If we allow QGA to execute arbitrary commands, running those commands
unconfined_t, then what is the point of having any SELinux policy
for QGA at all. It can just execute "/bin/sh" or "/bin/perl", passing
any script commands it wants, having them run as unconfined_t and thus
escape all SELinux confinement of QGA.

I didn't realize that we in fact already allowed runing any command
labelled bin_t. That already makes the QGA policy useless as a security
measure and should be addressed IMHO by putting that existing rul;e
behind a boolean, defaulting to disabled.

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