dbus insecure over secure TCP?

[L A Walsh]

Rémi Denis-Courmont wrote:
> Le perjantaina 13. heinäkuuta 2018, 20.33.32 EEST L A Walsh a écrit :
>   
>> fr:https://dbus.freedesktop.org/doc/dbus-specification.html#transports-tcp-s
>> 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
>>     insecure
>>
>>
>> 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.

>  And 
> 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
bus?

> 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 
secure
as appropriate.

    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.