qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add dbus-vmstate
Date: Fri, 23 Aug 2019 15:09:26 +0100
User-agent: Mutt/1.12.0 (2019-05-25)

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
> <address@hidden> wrote:
> >
> > * Daniel P. Berrangé (address@hidden) 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 via email to

[Prev in Thread] Current Thread [Next in Thread]