xref: /openbmc/qemu/docs/interop/dbus.rst (revision c09124dc)
1=====
2D-Bus
3=====
4
5Introduction
6============
7
8QEMU may be running with various helper processes involved:
9 - vhost-user* processes (gpu, virtfs, input, etc...)
10 - TPM emulation (or other devices)
11 - user networking (slirp)
12 - network services (DHCP/DNS, samba/ftp etc)
13 - background tasks (compression, streaming etc)
14 - client UI
15 - admin & cli
16
17Having several processes allows stricter security rules, as well as
18greater modularity.
19
20While QEMU itself uses QMP as primary IPC (and Spice/VNC for remote
21display), D-Bus is the de facto IPC of choice on Unix systems. The
22wire format is machine friendly, good bindings exist for various
23languages, and there are various tools available.
24
25Using a bus, helper processes can discover and communicate with each
26other easily, without going through QEMU. The bus topology is also
27easier to apprehend and debug than a mesh. However, it is wise to
28consider the security aspects of it.
29
30Security
31========
32
33A QEMU D-Bus bus should be private to a single VM. Thus, only
34cooperative tasks are running on the same bus to serve the VM.
35
36D-Bus, the protocol and standard, doesn't have mechanisms to enforce
37security between peers once the connection is established. Peers may
38have additional mechanisms to enforce security rules, based for
39example on UNIX credentials.
40
41The daemon can control which peers can send/recv messages using
42various metadata attributes, however, this is alone is not generally
43sufficient to make the deployment secure.  The semantics of the actual
44methods implemented using D-Bus are just as critical. Peers need to
45carefully validate any information they received from a peer with a
46different trust level.
47
48dbus-daemon policy
49------------------
50
51dbus-daemon can enforce various policies based on the UID/GID of the
52processes that are connected to it. It is thus a good idea to run
53helpers as different UID from QEMU and set appropriate policies.
54
55Depending on the use case, you may choose different scenarios:
56
57 - Everything the same UID
58
59   - Convenient for developers
60   - Improved reliability - crash of one part doesn't take
61     out entire VM
62   - No security benefit over traditional QEMU, unless additional
63     unless additional controls such as SELinux or AppArmor are
64     applied
65
66 - Two UIDs, one for QEMU, one for dbus & helpers
67
68   - Moderately improved user based security isolation
69
70 - Many UIDs, one for QEMU one for dbus and one for each helpers
71
72   - Best user based security isolation
73   - Complex to manager distinct UIDs needed for each VM
74
75For example, to allow only ``qemu`` user to talk to ``qemu-helper``
76``org.qemu.Helper1`` service, a dbus-daemon policy may contain:
77
78.. code:: xml
79
80  <policy user="qemu">
81     <allow send_destination="org.qemu.Helper1"/>
82     <allow receive_sender="org.qemu.Helper1"/>
83  </policy>
84
85  <policy user="qemu-helper">
86     <allow own="org.qemu.Helper1"/>
87  </policy>
88
89
90dbus-daemon can also perform SELinux checks based on the security
91context of the source and the target. For example, ``virtiofs_t``
92could be allowed to send a message to ``svirt_t``, but ``virtiofs_t``
93wouldn't be allowed to send a message to ``virtiofs_t``.
94
95See dbus-daemon man page for details.
96
97Guidelines
98==========
99
100When implementing new D-Bus interfaces, it is recommended to follow
101the "D-Bus API Design Guidelines":
102https://dbus.freedesktop.org/doc/dbus-api-design.html
103
104The "org.qemu.*" prefix is reserved for services implemented &
105distributed by the QEMU project.
106
107QEMU Interfaces
108===============
109
110:doc:`dbus-vmstate`
111