qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate
Date: Fri, 23 Aug 2019 15:09:26 +0100	[thread overview]
Message-ID: <20190823140926.GI9654@redhat.com> (raw)
In-Reply-To: <CAJ+F1CKTsQC1fULFG-hbUZ=Ao654K-TE6Fm9c1V+eRdAjk9QRA@mail.gmail.com>

On Fri, Aug 23, 2019 at 05:48:37PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Fri, Aug 23, 2019 at 5:00 PM Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> >
> > <snip>
> >
> > > This means QEMU still has to iterate over every single client
> > > on the bus to identify them. If you're doing that, there's
> > > no point in owning a well known service at all. Just iterate
> > > over the unique bus names and look for the exported object
> > > path /org/qemu/VMState
> > >
> >
> > Not knowing anything about DBus security, I want to ask how do
> > we handle security here?
> 
> First of all, we are talking about cooperative processes, and having a
> specific bus for each qemu instance. So some amount of security/trust
> is already assumed.
> 
> But if necessary, dbus can enforce policies on who is allowed to own a
> name, or to send/receive message from. As far as I know, this is
> mostly user/group policies.

Yep, the bulk of dbus policy restrictions are tied to user/groups.
After all, if two processes are under the same user ID, in general
any restrictions dbus tried to place on them are worthless as they
can simply attack each other outside dbus.

Running helpers as different UID from QEMU itself makes sense.

Running every single helper as a distinct UID is likely unmanagably
complex - especially if the helpers need certain privileges to
do their job.

> But there is also SELinux checks to send_msg and acquire_svc (see
> dbus-daemon(1))

SELinux gives us more fine grained control.

For example, consider each vhost user helper process

   "virtiofs_t" 

and QEMU is "svirt_t"

You can write a rule which says  svirt_t can send messages
to virtiofs_t, which allows QEMU to talk to the helpers.

Two helper processes both running "virtiofs_t" will, however,
not be able to talk to each other.


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:[~2019-08-23 14:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 15:03 [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate Marc-André Lureau
2019-08-08 15:03 ` [Qemu-devel] [PATCH v2 1/2] qemu-file: move qemu_{get, put}_counted_string() declarations Marc-André Lureau
2019-08-09 18:32   ` Dr. David Alan Gilbert
2019-08-08 15:03 ` [Qemu-devel] [PATCH v2 2/2] Add dbus-vmstate object Marc-André Lureau
2019-08-08 15:07   ` Marc-André Lureau
2019-08-22 10:55   ` Dr. David Alan Gilbert
2019-08-22 11:35     ` Marc-André Lureau
2019-08-22 11:41       ` Dr. David Alan Gilbert
2019-08-22 11:57         ` Marc-André Lureau
2019-08-22 12:19           ` Dr. David Alan Gilbert
2019-08-22 12:38             ` Marc-André Lureau
2019-08-22 12:51               ` Dr. David Alan Gilbert
2019-08-23 11:20 ` [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate Daniel P. Berrangé
2019-08-23 11:31   ` Marc-André Lureau
2019-08-23 11:41     ` Daniel P. Berrangé
2019-08-23 11:47       ` Marc-André Lureau
2019-08-23 13:00       ` Dr. David Alan Gilbert
2019-08-23 13:48         ` Marc-André Lureau
2019-08-23 14:09           ` Daniel P. Berrangé [this message]
2019-08-23 14:09           ` Dr. David Alan Gilbert
2019-08-23 14:20             ` Daniel P. Berrangé
2019-08-23 14:26               ` Dr. David Alan Gilbert
2019-08-23 14:40                 ` Daniel P. Berrangé
2019-08-23 14:56                   ` Dr. David Alan Gilbert
2019-08-23 15:05                     ` Daniel P. Berrangé
2019-08-23 15:14                       ` Dr. David Alan Gilbert
2019-08-23 15:21                         ` Daniel P. Berrangé
2019-08-23 15:24                           ` Dr. David Alan Gilbert

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=20190823140926.GI9654@redhat.com \
    --to=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).