From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "Laurent Vivier" <lvivier@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Marc-André Lureau" <marcandre.lureau@gmail.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:20:54 +0100 [thread overview]
Message-ID: <20190823142054.GK9654@redhat.com> (raw)
In-Reply-To: <20190823140948.GI2784@work-vm>
On Fri, Aug 23, 2019 at 03:09:48PM +0100, Dr. David Alan Gilbert wrote:
> * Marc-André Lureau (marcandre.lureau@gmail.com) 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.
>
> Some but we need to keep it as limited as possible; for example two
> reasons for having separate processes both come down to security:
>
> a) vtpm - however screwy the qemu is, you can never get to the keys in
> the vtpm
Processes connected to dbus can only call the DBus APIs that vtpm
actually exports. The vtpm should simply *not* export a DBus
API that allows anything to fetch the keys.
If it did want to export APIs for fetching keys, then we would
have to ensure suitable dbus /selinux policy was created to
prevent unwarranted access.
> b) virtio-gpu, loads of complex GPU code that can't break the main
> qemu process.
That's no problem - virtio-gpu crashes, it disappears from the dbus
bus, but everything else keeps running.
> > 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.
> >
> > But there is also SELinux checks to send_msg and acquire_svc (see
> > dbus-daemon(1))
>
> But how does something like SELinux interact with a private dbus
> rather than the system dbus?
There's already two dbus-daemon's on each host - the system one and
the session one, and they get different selinux contexts,
system_dbus_t and unconfined_dbus_t.
Since libvirt would be responsible for launching these private dbus
daemons it would be easy to make it run svirt_dbus_t for example.
Actually it would be svirt_dbus_t:s0:cNNN,cMMM to get uniqueness
per VM.
Will of course require us to talk to the SELinux maintainers to
get some sensible policy rules created.
> > > I want to know that the external device that's giving me migration data
> > > is the device I think I'm speaking to, not one of the other devices;
> >
> > DBus is not the problem nor the solution here.
>
> Well, if the migration data was squirting down the existing vhost-user
> channel then there would be no risk here; so the use of dbus is creating
> the problem.
>
> > But what defines that device-service strong relationship? Can you
> > generalize it? I don't think so.
> >
> > What DBus can guarantee is that the unique-id you are talking to is
> > always the same connection (thus the same process).
> >
> > > I also dont want different devices chatting to each other over dbus
> > > unless we're very careful.
> >
> > That's a bus policy job.
>
> OK, as long as you somehow set it up.
>
> Dave
>
> > >
> > > Dave
> > >
> > > > 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 :|
> > > --
> > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > >
> >
> >
> > --
> > Marc-André Lureau
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
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 :|
next prev parent reply other threads:[~2019-08-23 14:24 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é
2019-08-23 14:09 ` Dr. David Alan Gilbert
2019-08-23 14:20 ` Daniel P. Berrangé [this message]
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=20190823142054.GK9654@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).