Re: [Qemu-devel] [PATCH v3 5/6] docs: start a document to describe D-Bus usage

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Sep 12, 2019 at 04:25:13PM +0400, Marc-André Lureau wrote:
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
>  docs/interop/index.rst |  1 +
>  2 files changed, 74 insertions(+)
>  create mode 100644 docs/interop/dbus.rst
> 
> diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> new file mode 100644
> index 0000000000..c08f026edc
> --- /dev/null
> +++ b/docs/interop/dbus.rst
> @@ -0,0 +1,73 @@
> +=====
> +D-Bus
> +=====
> +
> +Introduction
> +============
> +
> +QEMU may be running with various helper processes involved:
> + - vhost-user* processes (gpu, virtfs, input, etc...)
> + - TPM emulation (or other devices)
> + - user networking (slirp)
> + - network services (DHCP/DNS, samba/ftp etc)
> + - background tasks (compression, streaming etc)
> + - client UI
> + - admin & cli
> +
> +Having several processes allows stricter security rules, as well as
> +greater modularity.
> +
> +While QEMU itself uses QMP as primary IPC (and Spice/VNC for remote
> +display), D-Bus is the de facto IPC of choice on Unix systems. The
> +wire format is machine friendly, good bindings exist for various
> +languages, and there are various tools available.
> +
> +Using a bus, helper processes can discover and communicate with each
> +other easily, without going through QEMU. The bus topology is also
> +easier to apprehend and debug than a mesh. However, it is wise to
> +consider the security aspects of it.
> +
> +Security
> +========
> +
> +A QEMU D-Bus bus should be private to a single VM. Thus, only
> +cooperative tasks are running on the same bus to serve the VM.
> +
> +D-Bus, the protocol and standard, doesn't have mechanisms to enforce
> +security between peers once the connection is established. Peers may
> +have additional mechanisms to enforce security rules, based for
> +example on UNIX credentials.
> +
> +dbus-daemon can enforce various policies based on the UID/GID of the
> +processes that are connected to it. It is thus a good idea to run
> +helpers as different UID from QEMU and set appropriate policies (so
> +helper processes are only allowed to talk to qemu for example).

We should also recommend that the daemon itself be run as separate
UID from QEMU, otherwise a compromised QEMU can trivially compromise
the dbus daemon too.

I'd say three scenarios are reasonable to document

 - Everything the same UID.
     - Convenient for developers
     - Improved reliability - crash of one part doens't take
       out entire VM
     - No security benefit over traditional QEMU

 - Two UIDs, one for QEMU, one for dbus & helpers
     - Moderately improved security isolation

 - Many UIDs, one for QEMU one for dbus and one for each helpers
     - Best security isolation
     - Complex to manager distinct UIDs needed for each VM


Documenting SELinux scenarios is probably a bit out of scope for
this.

We probably need to mention about the trust semantics associated
with messages sent over the bus.

ie, just because the daemon has controlled who can send/recv
messages to who, doesn't magically make this secure.

The semantics of the actual methods implemented using dbus
are just as critical. Peers need to carefully validate any
information they received from a peer with a different trust
level.

> +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> +``org.qemu.Helper1`` service:
> +
> +.. code:: xml
> +
> +  <policy user="qemu">
> +     <allow send_destination="org.qemu.Helper1"/>
> +     <allow receive_sender="org.qemu.Helper1"/>
> +  </policy>
> +
> +  <policy user="qemu-helper">
> +     <allow own="org.qemu.Helper1"/>
> +  </policy>
> +
> +
> +dbus-daemon can also perfom SELinux checks based on the security
> +context of the source and the target. For example, ``virtiofs_t``
> +could be allowed to send a message to ``svirt_t``, but ``virtiofs_t``
> +wouldn't be allowed to send a message to ``virtiofs_t``.

> +Guidelines
> +==========
> +
> +When implementing new D-Bus interfaces, it is recommended to follow
> +the "D-Bus API Design Guidelines":
> +https://dbus.freedesktop.org/doc/dbus-api-design.html
> +
> +The "org.qemu*" prefix is reserved for the QEMU project.

s/org.qemu*/org.qemu.*/ - we can't claim ownership of every
possible domain name with 'qemu' as a prefix.


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