Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> --- MAINTAINERS | 5 ++ docs/interop/dbus.rst | 105 +++++++++++++++++++++++++++++++++++++++++ docs/interop/index.rst | 1 + 3 files changed, 111 insertions(+) create mode 100644 docs/interop/dbus.rst
diff --git a/MAINTAINERS b/MAINTAINERS index 7a0ea36717..c0faf5377d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2204,6 +2204,11 @@ F: tests/migration-test.c F: docs/devel/migration.rst F: qapi/migration.json +D-Bus +M: Marc-André Lureau <marcandre.lur...@redhat.com> +S: Maintained +F: docs/interop/dbus.rst + Seccomp M: Eduardo Otubo <ot...@redhat.com> S: Supported 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. diff --git a/docs/interop/index.rst b/docs/interop/index.rst index 3e33fb5933..ded134ea75 100644 --- a/docs/interop/index.rst +++ b/docs/interop/index.rst @@ -13,6 +13,7 @@ Contents: :maxdepth: 2 bitmaps + dbus live-block-operations pr-helper qemu-ga -- 2.24.0.308.g228f53135a
