From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wE83EwfHv2XD/RIAWB0awg (envelope-from ) for ; Sun, 04 Feb 2024 12:19:03 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=k2YVFBII; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 49A771E0C3; Sun, 4 Feb 2024 12:19:03 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 351C81E092 for ; Sun, 4 Feb 2024 12:19:01 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A45CF3858004 for ; Sun, 4 Feb 2024 17:19:00 +0000 (GMT) Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id CB4433858CDB for ; Sun, 4 Feb 2024 17:18:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB4433858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CB4433858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707067123; cv=none; b=PWPNVxqqiNYuqmuMIPcNM5gDYoY9/i2vgF0/U17x9XEm+RoHFOO0/inYEnOKfLHmM6k4bPDOddPHWV2r5p8SJWh9UrBMoDooKtqtS8L0H9SHxxYswKuS5UuO3kl+4D9NZVrJFb+RXYHaNMrEigG4KIBh/Lc9cq33uxplQzvU3Ic= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707067123; c=relaxed/simple; bh=AQxtUxwagsOBxcO2RYwHxMOXYPWNPY7ESdK777i7ZQ0=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=ZiEVzqTni4TXPAMi2fSfAUeyTbXJIGmfvTpveIzsTz2Hc/4pmIU/Wf2hU1/ooHi50+hMMCXd9KVuj1rKMYMWN1v0dd0Mfgeh7QOKS/FgcNOE1P0nE5OBsGuj+JYHyDFsi0Mqs+OsJ1+fEz3JbU2qO3UfGeZiXfn6ynxQKSGuUQU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWg8a-0003sP-0c; Sun, 04 Feb 2024 12:18:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=16oiZwiKdfZ74iXTrVyCNTeDRb9O53M1ZOrx9O/lYOw=; b=k2YVFBII0UFc 0SJ3znCmGPhZOgsvCoaE7i3tAGliNW3nY/F8Q+MpGNQ1myYJOnPecEN11O6q6PQp907Q0dRG2TFhi 7na8Z3j6gMRaM4hV+LR8ITalZVQEcUyhiOGHdCmnS8eFopQ6zaXqJweY+ge0hghyNgJuuHSLPjWox 9erqqG00NYxk6fiPvLS7sHpgjpo5Pv494zyWG7BRYK+o+yVMWr5PI7VwxFXm5sFk9Z9PbUpWDg9gZ PAU/2vUHJMltLPYfaAbZ315Z+O5lKCXrn14GRwW0FEHmnPrWQuHV5XDnm3z1DrIJdTm7lfHnkKbAO Kp7ZP4QfdzLByIozB1J+Tw==; Date: Sun, 04 Feb 2024 19:18:33 +0200 Message-Id: <8634u82lna.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com, simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net In-Reply-To: <877cjk5jo5.fsf@redhat.com> (message from Andrew Burgess on Sun, 04 Feb 2024 15:32:58 +0000) Subject: Re: [RFC] Adding a SECURITY policy for GDB References: <877cmvui64.fsf@redhat.com> <87wmtog2f4.fsf@redhat.com> <83cyvfy7a2.fsf@gnu.org> <877cjk5jo5.fsf@redhat.com> X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org > From: Andrew Burgess > Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com, > simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net > Date: Sun, 04 Feb 2024 15:32:58 +0000 > > >> Any bugs in GDB that result in execution of the program being > >> debugged without a user issued GDB command triggering execution > > ^^^^^^ > > "issuing" > > > >> (either from the GDB command line, a GDB configuration file, or from > >> the GDB prompt) are considered security bugs. > > > > Is any execution of the program triggered by starting GDB considered > > "a command issued by the user"? IOW, are we sure GDB will never cause > > some program code to be executed just as result of the user saying > > > > $ gdb ./program > > > > ? The above text seems to assume that any such execution at startup > > must be the result of some command-line argument or some configuration > > file, but is that 110% certain, and are we sure this will _never_ > > change? > > Am I 110% certain? No. I'm never going to claim that level of > certainty on a topic. But I am 99% certain. > > Am I sure this will _never change? No. But that's OK. > > This document is about writing down an agreed project position on this > behaviour today. > > If tomorrow someone wants to propose a patch where 'gdb ./prog' would > automatically run './prog' then they are welcome to do so. But part of > that patch would require updating the SECURITY.txt document, and > hopefully, by touching the SECURITY.txt document, this would trigger a > conversation about whether we actually wanted to make that change. > > But that doesn't mean this document cannot be changed. > > FYI, right now, if someone did propose such a patch, I would be against > it being merged due to the possible security implications. What bothered me here is that when you say "gdb ./program", GDB can do two things which constitute code execution: . run some startup code in the program, for example, load some shared libraries, which could trigger execution of some code in those libraries, or . process various init files, which could invoke code in Python/Guile, or call functions inside the debuggee The second item actually happens when you say "gdb ./emacs" in the src directory of an Emacs source tree, because there's a .gdbinit file that which can call functions inside the executable and/or run Python code. Are these cases relevant to this part of the policy?