dbus-daemon(1): Mention and deprecate shared session buses

This might (?) have made sense behind a firewall in 2003; but now it's
2018, the typical threat model that we are defending against has
changed from "vandals want to feel proud of their l33t skills"
to "organised crime wants your money", and a "trusted" local LAN
probably contains an obsolete phone, tablet, games console or
Internet-of-Things-enabled toaster with remote root exploits.
This make network topologies that used to be acceptable look
increasingly irresponsible.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit d0a16b59a8572fbd1934e941e2e3004840306222)

1 files changed, 13 insertions, 0 deletions

diff --git a/doc/dbus-daemon.1.xml.in b/doc/dbus-daemon.1.xml.in
index 42e3f86f..960da080 100644
--- a/doc/dbus-daemon.1.xml.in
+++ b/doc/dbus-daemon.1.xml.in
@@ -432,6 +432,19 @@ a transport name plus possible parameters/options.</para>
   <!-- TODO: Ideally someone would write a more formal guide to
        remote D-Bus debugging, and we could link to that instead -->
 </para>
+<para>
+  Remote TCP connections were historically sometimes used to share
+  a single session bus between login sessions of the same user on
+  different machines within a trusted local area network, in
+  conjunction with unencrypted remote X11, a NFS-shared home
+  directory and NIS (YP) authentication. This is insecure against
+  an attacker on the same LAN and should be considered strongly
+  deprecated; more specifically, it is insecure in the same ways
+  and for the same reasons as unencrypted remote X11 and NFSv2/NFSv3.
+  The D-Bus maintainers
+  recommend using a separate session bus per (user, machine) pair,
+  only accessible from within that machine.
+</para>
 
 <para>Example: &lt;listen&gt;unix:path=/tmp/foo&lt;/listen&gt;</para>