From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87817 invoked by alias); 15 Oct 2018 11:28:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 87710 invoked by uid 89); 15 Oct 2018 11:28:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=risks X-HELO: jocasta.intra Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Oct 2018 11:28:14 +0000 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id w9FBS9ho000409 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Oct 2018 13:28:09 +0200 Received: (from john@localhost) by jocasta.intra (8.15.2/8.15.2/Submit) id w9FBS9uL000408; Mon, 15 Oct 2018 13:28:09 +0200 Date: Mon, 15 Oct 2018 11:28:00 -0000 From: John Darrington To: Simon Tatham Cc: John Darrington , gdb-patches@sourceware.org, nd@arm.com Subject: Re: [PATCH 2/4] GDB: Document the unix::/path/to/socket of remote connection. Message-ID: <20181015112809.nbggzudqroxn6wio@jocasta.intra> References: <20181013175801.2670-1-john@darrington.wattle.id.au> <20181013175801.2670-2-john@darrington.wattle.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-10/txt/msg00322.txt.bz2 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.