Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
 docs/interop/index.rst |  1 +
 2 files changed, 74 insertions(+)
 create mode 100644 docs/interop/dbus.rst

diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
new file mode 100644
index 0000000000..c08f026edc
--- /dev/null
+++ b/docs/interop/dbus.rst
@@ -0,0 +1,73 @@
+=====
+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.
+
+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 (so
+helper processes are only allowed to talk to qemu for example).
+
+For example, this allows only ``qemu`` user to talk to ``qemu-helper``
+``org.qemu.Helper1`` service:
+
+.. 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``.
+
+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 b4bfcab417..fa4478ce2e 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
    vhost-user
-- 
2.23.0

On Thu, Sep 12, 2019 at 04:25:13PM +0400, Marc-André Lureau wrote:
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
>  docs/interop/index.rst |  1 +
>  2 files changed, 74 insertions(+)
>  create mode 100644 docs/interop/dbus.rst
> 
> diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> new file mode 100644
> index 0000000000..c08f026edc
> --- /dev/null
> +++ b/docs/interop/dbus.rst
> @@ -0,0 +1,73 @@
> +=====
> +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.
> +
> +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 (so
> +helper processes are only allowed to talk to qemu for example).

We should also recommend that the daemon itself be run as separate
UID from QEMU, otherwise a compromised QEMU can trivially compromise
the dbus daemon too.

I'd say three scenarios are reasonable to document

 - 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


Documenting SELinux scenarios is probably a bit out of scope for
this.

We probably need to mention about the trust semantics associated
with messages sent over the bus.

ie, just 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 dbus
are just as critical. Peers need to carefully validate any
information they received from a peer with a different trust
level.

> +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> +``org.qemu.Helper1`` service:
> +
> +.. 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``.

> +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.

s/org.qemu*/org.qemu.*/ - we can't claim ownership of every
possible domain name with 'qemu' as a prefix.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

(Copying in Stefan since he was looking at DBus for virtiofs)

* Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
>  docs/interop/index.rst |  1 +
>  2 files changed, 74 insertions(+)
>  create mode 100644 docs/interop/dbus.rst
> 
> diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> new file mode 100644
> index 0000000000..c08f026edc
> --- /dev/null
> +++ b/docs/interop/dbus.rst
> @@ -0,0 +1,73 @@
> +=====
> +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.
> +
> +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 (so
> +helper processes are only allowed to talk to qemu for example).
> +
> +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> +``org.qemu.Helper1`` service:
> +
> +.. 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``.

I think we need to start thinking about this more now rather than
'can'. .

Dave

> +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 b4bfcab417..fa4478ce2e 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
>     vhost-user
> -- 
> 2.23.0
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Hi

On Mon, Sep 16, 2019 at 2:02 PM Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> (Copying in Stefan since he was looking at DBus for virtiofs)
>
> * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> >  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
> >  docs/interop/index.rst |  1 +
> >  2 files changed, 74 insertions(+)
> >  create mode 100644 docs/interop/dbus.rst
> >
> > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> > new file mode 100644
> > index 0000000000..c08f026edc
> > --- /dev/null
> > +++ b/docs/interop/dbus.rst
> > @@ -0,0 +1,73 @@
> > +=====
> > +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.
> > +
> > +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 (so
> > +helper processes are only allowed to talk to qemu for example).
> > +
> > +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> > +``org.qemu.Helper1`` service:
> > +
> > +.. 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``.
>
> I think we need to start thinking about this more now rather than
> 'can'. .

Do you have a specific question we can answer or guide for qemu? Is
there something we have to document or implement?

Since qemu is not managing the extra processes or applying policies, I
don't know what else could be done. From qemu pov, it can rely on
management layer to trust the bus and the helpers, similar to trusting
the system in general.

> Dave
>
> > +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 b4bfcab417..fa4478ce2e 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
> >     vhost-user
> > --
> > 2.23.0
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>


-- 
Marc-André Lureau

* Marc-André Lureau (marcandre.lureau@gmail.com) wrote:
> Hi
> 
> On Mon, Sep 16, 2019 at 2:02 PM Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > (Copying in Stefan since he was looking at DBus for virtiofs)
> >
> > * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > ---
> > >  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
> > >  docs/interop/index.rst |  1 +
> > >  2 files changed, 74 insertions(+)
> > >  create mode 100644 docs/interop/dbus.rst
> > >
> > > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> > > new file mode 100644
> > > index 0000000000..c08f026edc
> > > --- /dev/null
> > > +++ b/docs/interop/dbus.rst
> > > @@ -0,0 +1,73 @@
> > > +=====
> > > +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.
> > > +
> > > +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 (so
> > > +helper processes are only allowed to talk to qemu for example).
> > > +
> > > +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> > > +``org.qemu.Helper1`` service:
> > > +
> > > +.. 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``.
> >
> > I think we need to start thinking about this more now rather than
> > 'can'. .
> 
> Do you have a specific question we can answer or guide for qemu? Is
> there something we have to document or implement?
> 
> Since qemu is not managing the extra processes or applying policies, I
> don't know what else could be done. From qemu pov, it can rely on
> management layer to trust the bus and the helpers, similar to trusting
> the system in general.

Well pretty much the same questions I asked in the discussion on v2;
what is the supported configuration to ensure that one helper that's
been compromised can't attack the others and qemu?

Dave

> > Dave
> >
> > > +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 b4bfcab417..fa4478ce2e 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
> > >     vhost-user
> > > --
> > > 2.23.0
> > >
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> >
> 
> 
> -- 
> Marc-André Lureau
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Hi

On Mon, Sep 16, 2019 at 5:15 PM Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> * Marc-André Lureau (marcandre.lureau@gmail.com) wrote:
> > Hi
> >
> > On Mon, Sep 16, 2019 at 2:02 PM Dr. David Alan Gilbert
> > <dgilbert@redhat.com> wrote:
> > >
> > > (Copying in Stefan since he was looking at DBus for virtiofs)
> > >
> > > * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > > ---
> > > >  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
> > > >  docs/interop/index.rst |  1 +
> > > >  2 files changed, 74 insertions(+)
> > > >  create mode 100644 docs/interop/dbus.rst
> > > >
> > > > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> > > > new file mode 100644
> > > > index 0000000000..c08f026edc
> > > > --- /dev/null
> > > > +++ b/docs/interop/dbus.rst
> > > > @@ -0,0 +1,73 @@
> > > > +=====
> > > > +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.
> > > > +
> > > > +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 (so
> > > > +helper processes are only allowed to talk to qemu for example).
> > > > +
> > > > +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> > > > +``org.qemu.Helper1`` service:
> > > > +
> > > > +.. 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``.
> > >
> > > I think we need to start thinking about this more now rather than
> > > 'can'. .
> >
> > Do you have a specific question we can answer or guide for qemu? Is
> > there something we have to document or implement?
> >
> > Since qemu is not managing the extra processes or applying policies, I
> > don't know what else could be done. From qemu pov, it can rely on
> > management layer to trust the bus and the helpers, similar to trusting
> > the system in general.
>
> Well pretty much the same questions I asked in the discussion on v2;
> what is the supported configuration to ensure that one helper that's
> been compromised can't attack the others and qemu?

I thought I gave the answer to that question above. What is missing? I
don't think one can generalize it here, it will be a case by case for
each helper, how they interact with each other and qemu.

>
> Dave
>
> > > Dave
> > >
> > > > +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 b4bfcab417..fa4478ce2e 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
> > > >     vhost-user
> > > > --
> > > > 2.23.0
> > > >
> > > --
> > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > >
> >
> >
> > --
> > Marc-André Lureau
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



-- 
Marc-André Lureau

* Marc-André Lureau (marcandre.lureau@gmail.com) wrote:
> Hi
> 
> On Mon, Sep 16, 2019 at 5:15 PM Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > * Marc-André Lureau (marcandre.lureau@gmail.com) wrote:
> > > Hi
> > >
> > > On Mon, Sep 16, 2019 at 2:02 PM Dr. David Alan Gilbert
> > > <dgilbert@redhat.com> wrote:
> > > >
> > > > (Copying in Stefan since he was looking at DBus for virtiofs)
> > > >
> > > > * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

<snip>

> > > Do you have a specific question we can answer or guide for qemu? Is
> > > there something we have to document or implement?
> > >
> > > Since qemu is not managing the extra processes or applying policies, I
> > > don't know what else could be done. From qemu pov, it can rely on
> > > management layer to trust the bus and the helpers, similar to trusting
> > > the system in general.
> >
> > Well pretty much the same questions I asked in the discussion on v2;
> > what is the supported configuration to ensure that one helper that's
> > been compromised can't attack the others and qemu?
> 
> I thought I gave the answer to that question above. What is missing? I
> don't think one can generalize it here, it will be a case by case for
> each helper, how they interact with each other and qemu.

I think we need an example of how to lock it down; i.e. to allow a
helper to provide migration data but not to be able to speak to other
helpers.

Dave

> >
> > Dave
> >
> > > > Dave
> > > >
> > > > > +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 b4bfcab417..fa4478ce2e 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
> > > > >     vhost-user
> > > > > --
> > > > > 2.23.0
> > > > >
> > > > --
> > > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > > >
> > >
> > >
> > > --
> > > Marc-André Lureau
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 
> 
> 
> -- 
> Marc-André Lureau
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Hi

On Tue, Sep 17, 2019 at 12:12 PM Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
>
> * Marc-André Lureau (marcandre.lureau@gmail.com) wrote:
> > Hi
> >
> > On Mon, Sep 16, 2019 at 5:15 PM Dr. David Alan Gilbert
> > <dgilbert@redhat.com> wrote:
> > >
> > > * Marc-André Lureau (marcandre.lureau@gmail.com) wrote:
> > > > Hi
> > > >
> > > > On Mon, Sep 16, 2019 at 2:02 PM Dr. David Alan Gilbert
> > > > <dgilbert@redhat.com> wrote:
> > > > >
> > > > > (Copying in Stefan since he was looking at DBus for virtiofs)
> > > > >
> > > > > * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > > > > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> <snip>
>
> > > > Do you have a specific question we can answer or guide for qemu? Is
> > > > there something we have to document or implement?
> > > >
> > > > Since qemu is not managing the extra processes or applying policies, I
> > > > don't know what else could be done. From qemu pov, it can rely on
> > > > management layer to trust the bus and the helpers, similar to trusting
> > > > the system in general.
> > >
> > > Well pretty much the same questions I asked in the discussion on v2;
> > > what is the supported configuration to ensure that one helper that's
> > > been compromised can't attack the others and qemu?
> >
> > I thought I gave the answer to that question above. What is missing? I
> > don't think one can generalize it here, it will be a case by case for
> > each helper, how they interact with each other and qemu.
>
> I think we need an example of how to lock it down; i.e. to allow a
> helper to provide migration data but not to be able to speak to other
> helpers.
>

That's the example policy I gave for dbus-dameon. Only qemu user can
talk to Helper1 (for ex, a helper migration interface). Only
qemu-helper user can claim Helper1.

You could have additionally other ways: selinux policy, p2p helpers
SCM credentials checks, or other methods.



-- 
Marc-André Lureau

On Mon, Sep 16, 2019 at 11:00:35AM +0100, Dr. David Alan Gilbert wrote:
> (Copying in Stefan since he was looking at DBus for virtiofs)
> 
> * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> >  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
> >  docs/interop/index.rst |  1 +
> >  2 files changed, 74 insertions(+)
> >  create mode 100644 docs/interop/dbus.rst
> > 
> > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> > new file mode 100644
> > index 0000000000..c08f026edc
> > --- /dev/null
> > +++ b/docs/interop/dbus.rst
> > @@ -0,0 +1,73 @@
> > +=====
> > +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.
> > +
> > +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 (so
> > +helper processes are only allowed to talk to qemu for example).
> > +
> > +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> > +``org.qemu.Helper1`` service:
> > +
> > +.. 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``.
> 
> I think we need to start thinking about this more now rather than
> 'can'. .

Thinking about DBus usage with helpers, as compared to the current state
with monolithic QEMU, the top priority is to ensure no degradation in
security vs current practice.

That is fairly easy from libvirt's POV - we simply need to make sure
that the dbus daemon and all helpers get given the same SELinux svirt_t
content as used for QEMU, so each QEMU is still siloed to the same
extent.

If SELinux is not enabled, then currently an out of the box libvirt
config only protects the host from QEMU, it doesn't protect QEMU
from other QEMUs, since they all run the same user ID.

It is possible to tell libvirt to run each QEMU as a separate user
ID if the mgmt app has a range of user IDs avalable. In this case,
we would simply run the helpers/dbus as the same per-QEMU user ID
to ensure we don't regress.


Getting an improved security model is obviously the ultimate goal,
as this modularity needs to offer some benefit to outweight its
costs.

In terms of SELinux, this will involve creating distinct SElinux
contexts for each helper process. (svirt_slirp_t, svirt_swtpm_t,
etc, etc).

In terms of DAC, in the per QEMU user ID scenario,  we would need
to allocate at least 2 UIDs for each QEMU process, so that helpers
would be separate from the QEMU. To be honest it would be better
if we had 3 UIDs, to the dbus daemon was separated from both the
helpers and QEMU.

This starts to sound like alot of UIDs which is tedious to manage.
Libvirt already puts QEMU in a separate mount namespace. From a
DAC POV, to get meaninguful separation will probably want libvirt
to consider the "user" namespace too. This is quite a bit of work
to get everything labelled right for  different user namespace,
but it may well simplify mgmt thereafter. We still have the same
problem though, of needing to assign a range of user IDs for each
user namespace.

Overall, I can see the possible technical options for securing
this use of DBus, so I'm not too concerned here.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Mon, Sep 16, 2019 at 11:00:35AM +0100, Dr. David Alan Gilbert wrote:
> > (Copying in Stefan since he was looking at DBus for virtiofs)
> > 
> > * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > > ---
> > >  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
> > >  docs/interop/index.rst |  1 +
> > >  2 files changed, 74 insertions(+)
> > >  create mode 100644 docs/interop/dbus.rst
> > > 
> > > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> > > new file mode 100644
> > > index 0000000000..c08f026edc
> > > --- /dev/null
> > > +++ b/docs/interop/dbus.rst
> > > @@ -0,0 +1,73 @@
> > > +=====
> > > +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.
> > > +
> > > +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 (so
> > > +helper processes are only allowed to talk to qemu for example).
> > > +
> > > +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> > > +``org.qemu.Helper1`` service:
> > > +
> > > +.. 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``.
> > 
> > I think we need to start thinking about this more now rather than
> > 'can'. .
> 
> Thinking about DBus usage with helpers, as compared to the current state
> with monolithic QEMU, the top priority is to ensure no degradation in
> security vs current practice.
> 
> That is fairly easy from libvirt's POV - we simply need to make sure
> that the dbus daemon and all helpers get given the same SELinux svirt_t
> content as used for QEMU, so each QEMU is still siloed to the same
> extent.
> 
> If SELinux is not enabled, then currently an out of the box libvirt
> config only protects the host from QEMU, it doesn't protect QEMU
> from other QEMUs, since they all run the same user ID.
>
> It is possible to tell libvirt to run each QEMU as a separate user
> ID if the mgmt app has a range of user IDs avalable. In this case,
> we would simply run the helpers/dbus as the same per-QEMU user ID
> to ensure we don't regress.
> 
> 
> Getting an improved security model is obviously the ultimate goal,
> as this modularity needs to offer some benefit to outweight its
> costs.
> 
> In terms of SELinux, this will involve creating distinct SElinux
> contexts for each helper process. (svirt_slirp_t, svirt_swtpm_t,
> etc, etc).
> 
> In terms of DAC, in the per QEMU user ID scenario,  we would need
> to allocate at least 2 UIDs for each QEMU process, so that helpers
> would be separate from the QEMU. To be honest it would be better
> if we had 3 UIDs, to the dbus daemon was separated from both the
> helpers and QEMU.
> 
> This starts to sound like alot of UIDs which is tedious to manage.
> Libvirt already puts QEMU in a separate mount namespace. From a
> DAC POV, to get meaninguful separation will probably want libvirt
> to consider the "user" namespace too. This is quite a bit of work
> to get everything labelled right for  different user namespace,
> but it may well simplify mgmt thereafter. We still have the same
> problem though, of needing to assign a range of user IDs for each
> user namespace.

A separate user namespace might cause problems for things like
virtiofs where it's trying to access the files with particular perms,
or with say a GPU where it needs access to a display.

Dave

> Overall, I can see the possible technical options for securing
> this use of DBus, so I'm not too concerned here.
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

On Mon, Sep 16, 2019 at 11:00:35AM +0100, Dr. David Alan Gilbert wrote:
> (Copying in Stefan since he was looking at DBus for virtiofs)
> 
> * Marc-André Lureau (marcandre.lureau@redhat.com) wrote:
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> >  docs/interop/dbus.rst  | 73 ++++++++++++++++++++++++++++++++++++++++++
> >  docs/interop/index.rst |  1 +
> >  2 files changed, 74 insertions(+)
> >  create mode 100644 docs/interop/dbus.rst
> > 
> > diff --git a/docs/interop/dbus.rst b/docs/interop/dbus.rst
> > new file mode 100644
> > index 0000000000..c08f026edc
> > --- /dev/null
> > +++ b/docs/interop/dbus.rst
> > @@ -0,0 +1,73 @@
> > +=====
> > +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.
> > +
> > +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 (so
> > +helper processes are only allowed to talk to qemu for example).
> > +
> > +For example, this allows only ``qemu`` user to talk to ``qemu-helper``
> > +``org.qemu.Helper1`` service:
> > +
> > +.. 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``.
> 
> I think we need to start thinking about this more now rather than
> 'can'. .

virtiofsd has two DBus interfaces:

1. org.qemu.Virtiofsd - the management interface

   We don't expect QEMU to communicate with this.  Administrators or
   management tools will connect to this.

2. dbus-vmstate - we'll probably need this for live migration

   This is for QEMU<->vhost-user device backend communication.

Stefan