All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Renaud Métrich" <rmetrich@redhat.com>
Cc: "Marc-André Lureau" <marcandre.lureau@gmail.com>,
	selinux@lists.fedoraproject.org, QEMU <qemu-devel@nongnu.org>
Subject: Re: qemu-ga guest-exec & SELinux
Date: Tue, 21 Jun 2022 10:30:33 +0100	[thread overview]
Message-ID: <YrGPuSm5J7gUiIl+@redhat.com> (raw)
In-Reply-To: <330400e6-5a5f-7f59-b93c-0a3dd5ce47b6@redhat.com>

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



      reply	other threads:[~2022-06-21  9:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20  9:44 qemu-ga guest-exec & SELinux Marc-André Lureau
2022-06-20 10:06 ` Daniel P. Berrangé
2022-06-21  8:42   ` Renaud Métrich
2022-06-21  9:30     ` Daniel P. Berrangé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YrGPuSm5J7gUiIl+@redhat.com \
    --to=berrange@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rmetrich@redhat.com \
    --cc=selinux@lists.fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.