Duly noted!
But as I already wrote to Lennart, this is for a home environment.
Besides my hobby as a programmer, in daily life I am a network admin. So
I am quite aware of all the dangers lurking. There is a reason I have
quite a bunch of vlans, vrfs and ssids. So believe me when I say there
will be no other trusted or rogue client able to connect to this tcp
socket than the one I allow. There is only the user level authentication
issue. But that's actually no real issue as there is only one "user"
user active in my home network (other than root etc.), me. No publicly
accessible network outlets or switchports, no ssids that allow unknown
clients etc...
So now we have wavered all responsibilities. Is it possible or is it not
possible? Dbus-broker listening on tcp? If it's not possible, my
question is answered and I can go move on.
Thanks!
On 20-01-2025 22:13, Simon McVittie wrote:
On Mon, 20 Jan 2025 at 20:19:01 +0100, Erik Slagter wrote:
So I'd rather have dbus-broker listening to a TCP socket and if that can't
be done, using dbus-daemon.
Please don't do either of these. Having a D-Bus "user bus" (session bus)
listening on TCP and willing to execute arbitrary code was a key part of
the safety-critical vulnerability and multi-billion-dollar recall described
in <https://www.bbc.co.uk/news/technology-33650491>.
(Or maybe it was the system bus, I'm not sure - either way, one of the
"real" buses.)
The D-Bus protocol does not include cryptographic security and is intended
to be used only over secure connections such as AF_UNIX sockets. When
D-Bus was originally designed in around 2000, computers were expensive,
easy to notice and assumed to be managed by professionals, and there
was a feeling that it was viable and realistic to have a secure LAN
with a perimeter firewall and everyone behind the firewall completely
trusted, and in particular people wanted to use D-Bus over TCP combined
with NFS home directories for some sort of distributed system. However,
this never really worked well.
Now that an attacker can get into your "secure" network by plugging in a
Raspberry Pi to a network socket, exploiting an unpatched vulnerability
in your networked lightbulb, or similar attack vectors, D-Bus over TCP
has gone from bad idea to extremely bad idea. Please don't do it.
The main reason that the reference dbus-daemon still supports D-Bus over
TCP is for portability to Windows, which only gained AF_UNIX sockets
recently, so on Windows it's conventional to use D-Bus over a socket
that is bound to 127.0.0.1. dbus-broker is Linux-only (not portable),
so it doesn't need that.
If you want to use D-Bus over a network in order to debug an embedded
device or something like that, I would recommend tunneling a connection
through ssh. systemd-stdio-bridge is very convenient for this.
smcv
(a dbus maintainer)
