diff options
author | Marc-André Lureau <marcandre.lureau@redhat.com> | 2019-09-12 16:03:32 +0400 |
---|---|---|
committer | Marc-André Lureau <marcandre.lureau@redhat.com> | 2020-01-06 18:41:32 +0400 |
commit | a566907f1b52c8e94d4add32f50fe9b7d8d12921 (patch) | |
tree | acd546dced6bedaa11cef829af4ac9f16e946019 /docs/interop/dbus.rst | |
parent | 3cad405babb461e3c70782c51415f0b64bc7540d (diff) |
docs: start a document to describe D-Bus usage
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Diffstat (limited to 'docs/interop/dbus.rst')
-rw-r--r-- | docs/interop/dbus.rst | 105 |
1 files changed, 105 insertions, 0 deletions
diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst new file mode 100644 index 0000000000..ef80d4204d --- /dev/null +++ b/docs/interop/dbus.rst @@ -0,0 +1,105 @@ +===== +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 doens'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 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``. + +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. |