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

[John Darrington <john at darrington dot wattle dot id dot au>]

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.