Re: [PATCH 2/4] GDB: Document the unix::/path/to/socket of remote connection.

Simon Tatham
2018-10-15T09:31:37Z

On 13/10/18 18:57, John Darrington wrote:
> +Alternatively you can use a Unix domain socket:
> +
> +@smallexample
> +target remote unix::/tmp/gdb-socket1
> +@end smallexample
> +@noindent
> +
> +This has the advantage that it'll not fail if the port number is already
> +in use.
> +

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.

Also, current versions of OpenSSH support general forwarding of
Unix-domain sockets over SSH connections. Using that, it should even be
possible to use this system for genuinely _remote_ debugging (i.e.
between different machines), without reintroducing the same security
hazard, because the Unix socket at each end is access-controlled, and
the network connection in between them is cryptographically protected.

Cheers,
Simon