From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WEuAE03BwGXU0hMAWB0awg (envelope-from ) for ; Mon, 05 Feb 2024 06:06:53 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KdbE0mKV; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4C5881E0C3; Mon, 5 Feb 2024 06:06:53 -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 2939A1E098 for ; Mon, 5 Feb 2024 06:06:51 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5BABE385840D for ; Mon, 5 Feb 2024 11:06:50 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 4152D3858CDB for ; Mon, 5 Feb 2024 11:06:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4152D3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4152D3858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707131188; cv=none; b=in9V+k0qPjlIRc4WiO2AqXRxYpETnYOi5shZ1kzKwTUQguo1+xs78xvmD3i44+oXhm03R1fOsMa4r5/njLEvKHTINY0EkMekD0pkC4AUnVe5919MA+PhwSIOZKb/XIuJpTtCAUJyL9HixowNdGdtZ51ehJnozXgPe8Fd+BuwxK8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707131188; c=relaxed/simple; bh=A7pY3kLW40CUerLhZ7QsCLUaBeM7F2LXijBoYKumg1k=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=l8YlwcSDR/efyjY6M/sHuYSmgz13rEkGlej5Y50n6WbD/H1vmRfzOcg0BxXyTXFBlOaEWC85KwEkenQST6w7PBylvJ5/aM88L337/V7Gd+dfd422OmPb7mZhMsciYKqGxXHoQZ3wJNP1aRVI2Kx3fQLmBeaS3gQMsw1H8BXmBig= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707131186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6LBK54qxXg71+IwBUVOvefRb2LDpMDdz0TXHIG8Wgeg=; b=KdbE0mKV+WRebvW+ChLKGxdHdlLL5k5sru2URv6cBp0KTcLM0GB1Y73Qwcc5x8kNsfLYS6 ErjRrTj8MFJX6f7yKEFDclK09r3TF22yL5KIXMqFv4T/33D/gO4bDgyBx/5mZuzf69Kj6B xnLSlewKTt5e/Fc93PABkS5VQg3Pe9c= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-253-UN9Z6EHCMmqVttH3Uar_pA-1; Mon, 05 Feb 2024 06:06:25 -0500 X-MC-Unique: UN9Z6EHCMmqVttH3Uar_pA-1 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-511501135e3so570078e87.2 for ; Mon, 05 Feb 2024 03:06:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707131183; x=1707735983; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6LBK54qxXg71+IwBUVOvefRb2LDpMDdz0TXHIG8Wgeg=; b=wHfCDSFwK8gY75IISf14nkGb4HVqM8K2bdmJBDxO0R6Sw4fq2/B675fVQN+nTfDQuv xK4zUEnLjUAuTvaSYtd61h4spsIaZWAy3dcObU3iyuRsD5YGmw1dfMI2U0iGMsjBE7Oe aTx2inwFBWoLCeKex+PjPoeGst7iCtidTY/t6sgfECJbBb33xxYOTPk/GnUkC3jm+EIA vSWxzoCSaJBFFDAgIEfWtGFO/38KkNJ4iWVQ/wVLkCXpjWeNjUJRqjYDwl0SxOlGoYAz S/T8Yd4sNRbS/gf+XaX+X0jevNghgPlq0P7BCAScWGw9OrC6wIwNydSd/5tQHNJitrB6 L+EQ== X-Gm-Message-State: AOJu0YzMm9caLXnfVZPOO0AVAdIoFFXSK7Qxt2nr73CGj1OJRxGtzhPd /7x8zjUa66QdP/If4QeGMti7AdlsK0aI8XFxoYveWn9Jqpk4LA5cS6LDm8O+Hy506lW7r8JnDBL 4H08txxSzkD6O3ldjarfzU8njrsvnTYV27lh0kkmjSpFfqgtVn6TkNIOBQa2CnLQ7wtc= X-Received: by 2002:a05:6512:368b:b0:511:5000:45d2 with SMTP id d11-20020a056512368b00b00511500045d2mr1366875lfs.1.1707131183354; Mon, 05 Feb 2024 03:06:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IFrBvgyfdJJkOsnMguX9DhpwFp0wiBiApibrRA61GL9y9Y2WMG6lCEG9mnkUHT2Q5VYBFBuOQ== X-Received: by 2002:a05:6512:368b:b0:511:5000:45d2 with SMTP id d11-20020a056512368b00b00511500045d2mr1366863lfs.1.1707131182999; Mon, 05 Feb 2024 03:06:22 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXaGXIhclFVD0KNbvALyeog5sG/jFiUFUHUd6dXUNCmobyNgrCfBE0CIT6Im07tCc6Y03j1wAhrvh0TgGhzvdy1WeoR4Q0AGL63Gch+faLxC/LlnEG4MJ3aV6qEbEYOthvaC3Q6GavpQUtlzTpE8Rw42dOJi9mWo6tVXS5MmalI5g5sS0X3bVeN8p46u83ifec1cDbI1aj7VUbSfSY= Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id p8-20020a056000018800b0033b3bb05e19sm2541855wrx.32.2024.02.05.03.06.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Feb 2024 03:06:22 -0800 (PST) From: Andrew Burgess To: Eli Zaretskii Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com, simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net Subject: Re: [RFC] Adding a SECURITY policy for GDB In-Reply-To: <8634u82lna.fsf@gnu.org> References: <877cmvui64.fsf@redhat.com> <87wmtog2f4.fsf@redhat.com> <83cyvfy7a2.fsf@gnu.org> <877cjk5jo5.fsf@redhat.com> <8634u82lna.fsf@gnu.org> Date: Mon, 05 Feb 2024 11:06:21 +0000 Message-ID: <87v87341ci.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 Eli Zaretskii writes: >> 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 In a pure GDB world I don't think this is correct. No inferior process is created until some user command, from _somewhere_ tells GDB to start a process. That might be from a `.gdbinit` file, but I have tried to cover this case by referencing 'configuration files'. No shared libraries will be loaded until the inferior process starts running. > . 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? You are correct that loading a particular executable might auto-load a configuration files, so maybe that needs to be specifically called out, but I do consider this covered by my mention of 'configuration files'. Without such a configuration files which starts the inferior then there should be no inferior execution. Maybe we do need to mention the auto-loading, and draw attention to the auto-load safe-path stuff, I'll see if I can work something about this in -- though I want to try and avoid being too specific, this isn't intended as a "how too", but more a high level policy document, but I think mentioning the idea of auto-loading, and that GDB will always make such auto-loading "opt-in" rather than "opt-out" is certainly something that the document should cover. Thanks, Andrew