From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wOXhMQtMxmVGbRgAWB0awg (envelope-from ) for ; Fri, 09 Feb 2024 11:00:11 -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=iJw937bi; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C5FCA1E0C3; Fri, 9 Feb 2024 11:00:11 -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 B25C21E098 for ; Fri, 9 Feb 2024 11:00:09 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5EE313858434 for ; Fri, 9 Feb 2024 16:00:08 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2AC1E3858404 for ; Fri, 9 Feb 2024 15:59:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2AC1E3858404 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 2AC1E3858404 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707494388; cv=none; b=TncgT3LYJmG1Vsvu0fodvcYOcRnP7pHhTy9xl+4/NmCOtz7rSixBWMB0XKHjnS2CAE+Q115B+QVeVMwjvU/EBSVNLbNk63Tur5OdjjKvdeyTU3FbALZrtbeYH23gKeyXFhfmPsIpHvq/HODaPic2WXQ6wmrDDx0abZNnpkvrXYs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707494388; c=relaxed/simple; bh=CC4oPFGbNWkNm95oT0EtA+BDfnj/rG2X0cwuSDpq0rg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OagbcdtJvoUPpWZq0TpaDLkKekxIMsTv4QY+dg6UCLOkH3CaS8xByGUWEcQytGjIcJOVdysjgWquY3FLutCeat+3LGmvlOSX76j6H+BQSBTCgObXSnRT8H6/bZrEr7vpQtoaE++qCDgBz1/47rLGlY61w4EjRWOzufELLEvFGZs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707494386; 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=kygwds8S0zNoD2BTyeT5MbcOw3Z0P7E4nQuz2whBg6A=; b=iJw937bi7PnZXqeF29KVv20LmEouNlg2nkoyAl1NjwkU1/iNWluOtx8ZgPQ8HQFL36WQQf D5o/vM4ksQcWUSgQqQr2tve9Fpjf3HTE8eepfKr5VodsGwiMn3fVrExV2KN9sQTimMMDds Xgd5ZSkyRgel8/fd21D4Ui+INzY6QJQ= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-604-Gw1nDcFzNb2mnf3v-tozBA-1; Fri, 09 Feb 2024 10:59:45 -0500 X-MC-Unique: Gw1nDcFzNb2mnf3v-tozBA-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-51156c3208cso996328e87.1 for ; Fri, 09 Feb 2024 07:59:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707494384; x=1708099184; 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=kygwds8S0zNoD2BTyeT5MbcOw3Z0P7E4nQuz2whBg6A=; b=NWX6ghwl69kijrLyyhXsmp+lqcImalYxVPrM1AzInUlV64dWPEYzbmNYTYa2JW0WOU 24qPOlODJY509WMz/tHwhd8XvjO9FpLc1ITS38vNbkxKZNGNZrL+0tWl+QTRI5Qxxcfq +dms505p/an36xo2UqehtDpwUKQof3Zv3r4EJojlisNYCpikIK3PbPa8IDKujH1DRZlS 57zEECaVkMpMr2b+8lkcZwqfukLjWNFjuEcO7FTO9b1vcuxqHhVVwtja/YVTjBop8MN2 XX/foHWAato1OaCpUBW2Db10qNYkIGMHwtXUbx0fnz4mbdDEPWW8wSNg4yoadufNjBlg DGlg== X-Gm-Message-State: AOJu0YxX8v2H/1VLneoUj6j84OxSlyPvKuoneZiaRqxNiKDCUr/FzgEd /cKB9Q+VpJcLwvW0lcZMHIfAqCCFcl9D7eAlX8UR9iY1ylMAORS4qd/CMsn41LMeRwEtBM7ejPO AjBIjQ4X/9S3DFwkYcsySw8URFWiIIvZvE374EY4BNJ/LCJPUlsUuXKtTly4= X-Received: by 2002:ac2:55a4:0:b0:511:4e85:5b2d with SMTP id y4-20020ac255a4000000b005114e855b2dmr1381214lfg.69.1707494383843; Fri, 09 Feb 2024 07:59:43 -0800 (PST) X-Google-Smtp-Source: AGHT+IHjPKGwc5GlZVTfTEbHCKabW1Hfs+ztPyq0U4XkyJ3wrCwpe1KYgx/vLZUKJaJX0yxfe5gkmw== X-Received: by 2002:ac2:55a4:0:b0:511:4e85:5b2d with SMTP id y4-20020ac255a4000000b005114e855b2dmr1381199lfg.69.1707494383499; Fri, 09 Feb 2024 07:59:43 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUmdUIMEvg3e9KAZRBRat7+wLjT7a5+Fej5x2s0utXCBbb9pb7rwDV/v0L+9jgn+/gVE/chniWdj4bl2l1Mbkh5YgJniCikprYNOoCkY0unrG17Bx+Di/vnpKL7CLUpqFiNyZG6+6qoK+DdjukPOCFvVQp6OTf0EemUQz/4Oc5ohP1X9UxXIDST3n364aSm+aQ1eVKcUqkmFKlozL4= Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id jd10-20020a05600c68ca00b0040fdc645beesm1020021wmb.20.2024.02.09.07.59.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Feb 2024 07:59:42 -0800 (PST) From: Andrew Burgess To: Tom Tromey Cc: gdb-patches@sourceware.org, Siddhesh Poyarekar , Kevin Buettner , Simon Marchi , felix.willgerodt@intel.com, Paul Koning Subject: Re: [RFC] Adding a SECURITY policy for GDB In-Reply-To: <87msseeibf.fsf@tromey.com> References: <877cmvui64.fsf@redhat.com> <87wmtog2f4.fsf@redhat.com> <87msseeibf.fsf@tromey.com> Date: Fri, 09 Feb 2024 15:59:42 +0000 Message-ID: <878r3t7hn5.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_H5, RCVD_IN_MSPIKE_WL, 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 Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> Apologies for taking so long to get a second version of this document > Andrew> prepared. I've been through several iterations of this text since I > Andrew> last posted trying to get something semi-reasonable... It would be great > Andrew> to get your feedback on this new text. > > Thank you for doing this. > > Andrew> So, instead, I've just given up on that. I think Simon, Paul, and > Andrew> Felix should find (at least this part of) the new text satisfactory; > Andrew> loading a binary, but not executing it, should be safe to do, and if > Andrew> that's not the case, then this is a security issue. > > I think this is what users expect, but I don't think this is at all in > line with what we can promise. We couldn't get consensus to deprecate > the stabs reader last year, but at the same time, nobody works on the > existing fuzzer bugs that have been reported against it (or was it > mdebugread?) ... the point being that there's a lot of > dead-but-vulnerable code. > > For the DWARF reader, this safety might be attainable, though given the > large number of DWARF scenarios, I am skeptical. In any case, this > promise definitely doesn't describe the situation *today*, where nobody > has seriously tried fuzzing, or even really looking through the more > obvious possible buffer overruns. > > To be clear, I'm not at all opposed to someone fixing fuzzer bugs. It's > clear to me that it ought to be done, even if it comes at some cost. > > Perhaps this is covered by the section recommending sandboxing. Thanks for your thoughts on this. What you've said is similar to discussions I've had within Red Hat on this topic. On one hand some argue the security policy should reflect the current state of GDB, and bugs that are found in areas of GDB which are known to be, maybe, not so robust, should not be classified as security bugs. The interest of folk in this group are mostly about reducing the number of security issues that are reported, so they'd like to see an upstream security policy which lets bugs reported as "security" be reclassified as "normal" upstream bugs. Then there's the view which was reflected (I think) in the initial feedback to my V1 proposal, and which is where I now sit. The security policy should be aspirational, lay out how we'd like things to be, and then, in theory, we can work towards that as a goal. But reading what you write, I think maybe there's a third position which sits somewhere between these two, and you're right that I do touch on this third position when I discuss sandboxing, but maybe I don't stress this enough? I should probably lay out where we'd like GDB to be, but then be more open and realistic about where GDB actually is. I think we're all agreeing that a user should be able to examine (without running) an untrusted binary and have this be risk free. But as you point out, and I don't think anyone will disagree with, right now that isn't really a safe thing to do, and really folk shouldn't be doing that. I also have some notes from Eli to fold in, so I'll take another pass at this next week and try to come up with a V4 which covers these ideas. Thanks for your feedback, Andrew > > Andrew> One last thing, while writing this, I did wonder if this text would be > Andrew> better moved into the GDB manual, and the gdb/SECURITY.txt document > Andrew> should just say "See the GDB manual", but I figure that's a problem for > Andrew> future me, for now I just need to find some words we can all agree on. > > I think this would be good. > > Tom