| Message ID | 20191211134506.1803403-4-marcandre.lureau@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add dbus-vmstate | expand |
On Wed, Dec 11, 2019 at 05:45:01PM +0400, Marc-André Lureau wrote: > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> > --- > MAINTAINERS | 5 +++ > docs/interop/dbus.rst | 99 ++++++++++++++++++++++++++++++++++++++++++ > docs/interop/index.rst | 1 + > 3 files changed, 105 insertions(+) > create mode 100644 docs/interop/dbus.rst > > diff --git a/MAINTAINERS b/MAINTAINERS > index 525b4740e8..19faa0e868 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2199,6 +2199,11 @@ F: tests/migration-test.c > F: docs/devel/migration.rst > F: qapi/migration.json > > +D-Bus > +M: Marc-André Lureau <marcandre.lureau@redhat.com> > +S: Maintained > +F: docs/interop/dbus.rst > + > Seccomp > M: Eduardo Otubo <otubo@redhat.com> > S: Supported > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst > new file mode 100644 > index 0000000000..3d760e4882 > --- /dev/null > +++ b/docs/interop/dbus.rst > @@ -0,0 +1,99 @@ > +===== > +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. However, because the daemon has > +controlled who can send/recv messages to who, doesn't magically make > +this secure. This reads a little awkwardly, instead: 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 In the last point add ', unless additional unless additional controls such as SELinux or AppArmor are applied'. > + > + - Two UIDs, one for QEMU, one for dbus & helpers > + > + - Moderately improved security isolation s/improved/improved user based/ > + > + - Many UIDs, one for QEMU one for dbus and one for each helpers > + > + - Best security isolation s/Best/Best user based/ > + - 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 the QEMU project. Perhaps change the last few words to '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 Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Regards, Daniel
diff --git a/MAINTAINERS b/MAINTAINERS index 525b4740e8..19faa0e868 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2199,6 +2199,11 @@ F: tests/migration-test.c F: docs/devel/migration.rst F: qapi/migration.json +D-Bus +M: Marc-André Lureau <marcandre.lureau@redhat.com> +S: Maintained +F: docs/interop/dbus.rst + Seccomp M: Eduardo Otubo <otubo@redhat.com> S: Supported diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst new file mode 100644 index 0000000000..3d760e4882 --- /dev/null +++ b/docs/interop/dbus.rst @@ -0,0 +1,99 @@ +===== +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. However, 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 +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 + + - 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 + +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 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
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> --- MAINTAINERS | 5 +++ docs/interop/dbus.rst | 99 ++++++++++++++++++++++++++++++++++++++++++ docs/interop/index.rst | 1 + 3 files changed, 105 insertions(+) create mode 100644 docs/interop/dbus.rst