112 lines
3.5 KiB
ReStructuredText
112 lines
3.5 KiB
ReStructuredText
=====
|
|
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.
|
|
|
|
The daemon can control which peers can send/recv messages using
|
|
various metadata attributes, however, this is alone is not generally
|
|
sufficient to make the deployment secure. The semantics of the actual
|
|
methods implemented using D-Bus are just as critical. Peers need to
|
|
carefully validate any information they received from a peer with a
|
|
different trust level.
|
|
|
|
dbus-daemon policy
|
|
------------------
|
|
|
|
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.
|
|
|
|
Depending on the use case, you may choose different scenarios:
|
|
|
|
- Everything the same UID
|
|
|
|
- Convenient for developers
|
|
- Improved reliability - crash of one part doesn't take
|
|
out entire VM
|
|
- No security benefit over traditional QEMU, unless additional
|
|
unless additional controls such as SELinux or AppArmor are
|
|
applied
|
|
|
|
- Two UIDs, one for QEMU, one for dbus & helpers
|
|
|
|
- Moderately improved user based security isolation
|
|
|
|
- Many UIDs, one for QEMU one for dbus and one for each helpers
|
|
|
|
- Best user based security isolation
|
|
- Complex to manager distinct UIDs needed for each VM
|
|
|
|
For example, to allow only ``qemu`` user to talk to ``qemu-helper``
|
|
``org.qemu.Helper1`` service, a dbus-daemon policy may contain:
|
|
|
|
.. 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 perform 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``.
|
|
|
|
See dbus-daemon man page for details.
|
|
|
|
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 services implemented &
|
|
distributed by the QEMU project.
|
|
|
|
QEMU Interfaces
|
|
===============
|
|
|
|
:doc:`dbus-vmstate`
|
|
|
|
:doc:`dbus-display`
|