dbus insecure over secure TCP?
L A Walsh
dbus at tlinx.org
Fri Jul 13 21:12:38 UTC 2018
Rémi Denis-Courmont wrote:
> Le perjantaina 13. heinäkuuta 2018, 20.33.32 EEST L A Walsh a écrit :
>> ockets says:
>> In particular, configuring the well-known system bus or the
>> well-known session bus to listen on a non-loopback TCP address is
>> Why? If the TCP-PATH between systems is secure, how is dbus insecure?
> In general, D-Bus over a TCP path is insecure.
Isn't it as secure as the network connection containing the TCP
link? I believe it was compared to 'X', which can be secure or insecure
depending on configuration.
> The D-Bus daemon and clients
> are not in a position to determine that the TCP path is secure or is not.
Neither is 'X', but the user is. and for the system bus, the OS
administrator(s) are. By the same token, creating a bridge between
and outside network and localnet could do the opposite.
> there is also the problem that the credential passing authentication mechanism
> for local domain sockets is in fact more secure than that for TCP sockets.
If I have 1 person per compartment on my set that is separate from
every other user, why do I need authentication from a user to their session
> As I understand it, this is a reminder that the TCP support was only intended
> as a substitute for local domain (Unix) sockets on Windows, not for general
> use over a network.
But I have situations where someone desktop is located on a remote
host, while 'X' is running locally. I have a mix of applications that
are run on the server and on the client. At one point, I had any attempt
to bring up a web browser on the server forward the request to the client so
as not to try to bring up a browser over 'X'. At no point was it insecure
nor was authentication needed.
>> Why is DBUS advertising that it is insecure when used over secure networks?
> The specification says nothing of "secure networks" actually.
The specification says little about the environment, other than
the user is running a desktop. But if their file resources are on the
network --- it would be assumed to be secure.
>> In addition to dedicated lines, TCP connections over VPNs and ssh have been
>> around for 30 years or more.
> Running D-Bus over TCP forwarded over SSH does not make any sense. With SSH,
> you can forward D-Bus over local domain socket - just like X11 forwarding.
Right, but from X-apps, they connect to DISPLAY[:1[.0]] -- they don't
know if that is a local domain socket or a TCP connection. Why wouldn't
the same be configurable with DBUS?
I.e if DBUS used the display ID to create a socket -- it wouldn't matter
if it was a local socket or TCP -- it would be hidden from dbus and no
problem. I think having DBUS be as unaware of the transport as X is,
is a desirable trait. Then no worries about DBUS setting security policy --
it just uses a generic transport where it is up to the user & admin to
The session paradigm doesn't do well when the session is bridged over
2 or more networked resources unless you are using 1 session. 'X' doesn't
get excessively into dictating security policy -- it mentions the issues,
but is constructed to not need to know. Why shouldn't DBUS be similar?
In my case, I'm wanting the two to function together -- in parallel,
that they'd adopt similar transport mechanisms would seem natural.
More information about the dbus