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

[Simon Tatham <Simon dot Tatham at arm dot com>]

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