This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/4] GDB: Document the unix::/path/to/socket of remote connection.
On Mon, Oct 15, 2018 at 10:31:01AM +0100, Simon Tatham wrote:
Hi,
I was pointed at this thread by a colleague, because last week I was also
considering submitting a patch to allow gdb and gdbserver to talk to each
other over Unix-domain sockets, and he pointed out that it was already in
progress :-)
I'd like to suggest that this documentation change under-stresses what I
see as the most important reason why this is a useful feature: security.
The gdbserver protocol is cleartext and unauthenticated. Running it on a
TCP port means that anyone who can connect to that port ??? and depending
on the network environment, that might be a lot of people ??? can request
gdbserver to execute arbitrary code in the context of the process being
debugged, without having to give a vestige of proof as to their right to
ask for it. This is not really the kind of feature we like about network
protocols in the modern world!
But Unix-domain sockets are access-controlled via the file permissions on
the path leading to the socket file. If you use this new feature to make
a Unix-domain socket inside a directory that only your user id has access
to, then any process physically capable of connecting to the socket has
already proved its right to run code under your user id. So this solves
the whole issue, while keeping all the other conveniences of the
socket-based gdbserver transport.
Cheers,
Simon
This is a good point. But really it belongs under the heading of the
risks associated with TCP/IP sockets - not the risk which is absent when
using Unix sockets.
The documentation already has this warning:
_Warning:_ 'gdbserver' does not have any built-in security. Do not
run 'gdbserver' connected to any public network; a GDB connection
to 'gdbserver' provides access to the target system with the same
privileges as the user running 'gdbserver'.
... perhaps that could be expanded to discuss the relative merits of
UDS vs. TCP/IP
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.