From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix) with ESMTPS id 7431A3858D28; Wed, 12 Apr 2023 16:26:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7431A3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6A74D410B4; Wed, 12 Apr 2023 16:26:24 +0000 (UTC) Received: from pdx1-sub0-mail-a305.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E7AE841BEE; Wed, 12 Apr 2023 16:26:23 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1681316784; a=rsa-sha256; cv=none; b=3V1kafUkJV2DpQEXZgu2w6oDYcHIKBOq2EWDcuqWIqLTsAzsn3Ag2ixUQpu+AW+lA9WpG3 AFI0b39X0Usy9M1EvqOXzrqaNm04gm7ymeMspuyrMvSKHGbvwRSvIkplzOCd61N77794Vd ODZonxI2E7P6K6FqyLpOkcnt1PAl9F9o7fmYSl6KM8qyiQOJZ5+N6v9EL3AhqYh94d+Sc+ 1oHtq2p/QP1Is//DyqYDLgl7BxODLPT7FcdcAwpmLc/TtmV13RelZ1hVJw0NdZ2NZa3ZRj qhDc4vP4nxwSOYjeIWBSw9q5Np/uLn2kSpwVUwwhbxYhBYpL+QTEpOU/TZ6xcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1681316784; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aGC78PlwKvf6GZei5vl7veCxp7pIp97jrd/3Q1w4N34=; b=WuD+HhtEa28YMJAQN98W7yoINaUAzEcf6peT2H5UOKzmXj1brPf3L7KgHGZRriEvDghB+4 aE+iVca7XKib/Vuf1XCUfInCjchxOxJ3i2M9y/fboovhcGcTzqqWJCp30BoCX0rP9ghboS LlM2gXCKYbhrDa4DDzyRusJoR5oL/t/RnJq2hI0oHuuvOF2RSWLAw78ZegWaQy2+sbBO9Z vjbh9vEzd1rlrwx0eAUOJlo9FChtRc38xU8Qu1n73DhsmWhJTfl7/JGRnL0c353H34j8WI m9SU2Kk2o2tJgC1oiE8GQ/UhkkXjcZn6xDbu4BSgsDsF1dn+i+yRrPUUPqPt+Q== ARC-Authentication-Results: i=1; rspamd-5468d68f6d-pw7rc; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Descriptive-Irritate: 09f0db6c29ef57e3_1681316784227_4189746416 X-MC-Loop-Signature: 1681316784227:2741997002 X-MC-Ingress-Time: 1681316784226 Received: from pdx1-sub0-mail-a305.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.102.66.14 (trex/6.7.2); Wed, 12 Apr 2023 16:26:24 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-09-174-91-45-153.dsl.bell.ca [174.91.45.153]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a305.dreamhost.com (Postfix) with ESMTPSA id 4PxSl32GtzzK1; Wed, 12 Apr 2023 09:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1681316783; bh=aGC78PlwKvf6GZei5vl7veCxp7pIp97jrd/3Q1w4N34=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=pGafXWhouFHpLGqpXlsCtNh8srTub5YusDwak6AX6iK77S4GlkHXoZfITNTe14XOo 1TgTY3VWCRzZt132AG6nsSEfub8giMpACEq5l2MmGzQuwd1vcgSxEDd/4wtyfsaqAh 7gxX9I+Kf70NvCdfCLIevHAQdEs7GFUTuMHJa75dmmuBKBmJeLtHUKy/yPec7ISH2P qpkT0msh4JROvIvzLPf9kl+6R5HngmqoXiJB6WXQOAatbvEPN10yb5AwCdsa+LMQWe fhZ68hntb/MQXJYoSD/JoaKvQqo1sFLOvpYNRyyNvDWuou3VapcWwMPyIIDCbar1kF 0QgJfvGNOh8gA== Message-ID: <5d044987-39eb-a060-1b2b-9d07b1515e7d@gotplt.org> Date: Wed, 12 Apr 2023 12:26:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: RFC: Adding a SECURITY.md document to the Binutils Content-Language: en-US To: Richard Earnshaw , Nick Clifton , Binutils Cc: "gdb@sourceware.org" References: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.com> <5b147005-bd28-4cf9-b9e7-479ef02cb1ad@foss.arm.com> From: Siddhesh Poyarekar In-Reply-To: <5b147005-bd28-4cf9-b9e7-479ef02cb1ad@foss.arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3027.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,MEDICAL_SUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-04-12 12:02, Richard Earnshaw wrote: > > > On 07/04/2023 09:42, Nick Clifton via Binutils wrote: >> Hi Guys, >> >>    Many open source projects have a SECURITY.md file which explains >>    their stance on security related bugs.  So I thought that it would >>    be a good idea if we had one too.  The top level file would actually >>    just be a placeholder, like this: >> >> ------------- ./SECURITY.md ------------------------------------------ >> For details on the Binutils security process please see >> the SECURITY.md file in the binutils sub-directory. >> >> For details on the GDB security process please see >> the SECURITY.md file in the gdb sub-directory. >> -------------------------------------------------------------------- >> >>    So this email is mostly about the wording for the Binutils specific >>    version.  Here is my current proposal: >> >> ---------------- binutils/SECURITY.md ------------------------------ >> Binutils Security Process >> ========================= >> >> What is a binutils security bug? >> ================================ >> >>     A security bug is one that threatens the security of a system or >>     network.  In the context of the GNU Binutils this means a bug that >>     relates to the creation of corrupt output files from valid, trusted >>     inputs.  Even then the bug would only have a security impact if the >>     the code invokes undefined behaviour or results in a privilege >>     boundary being crossed. >> >>     Other than that, all other bugs will be treated as non-security >>     issues.  This does not mean that they will be ignored, just that >>     they will not be given the priority that is given to security bugs. >> >>     This stance applies to the creation tools in the GNU Binutils (eg >>     as, ld, gold, objcopy) and the libraries that they use.  Bugs in >>     inspection tools (eg readelf, nm objdump) will not be considered >>     to be security bugs, since they do not create executable output >>     files.  When used on untrusted inputs, these inspection tools >>     should be appropriately sandboxed to mitigate potential damage >>     due to any malicious input files. > > I'd expect that any program used on untrusted input to be run only at > user-level privileges.  So we should exclude issues where an account > with elevated privileges (eg root) is used with either inspection or > generation tools. Agreed, I think this should be addressed by the "or results in a privilege boundary being crossed". By running these programs as root, the user is elevating privileges themselves, so it's not a binutils problem. Perhaps it's necessary to educate users to not run these programs as root, but I don't think it is the intent of SECURITY.md to educate users about secure usage. The intent is to define context by describing what constitutes security-relevant bugs and then document mechanisms to reach out to communicate those bugs in case they're sensitive. > The other area of concern is where the tools (particularly the linker) > 'generate' code; so bugs in the opcodes the assembler generates (eg by > not setting some don't care bits to something safe) or with code > generated by the linker to glue functions together (relocation handling, > PLTs, veneers, etc) would also count. Ack, I reckon this should be addressed by "corrupt output files from valid trusted inputs". If that's not clear enough, could you suggest alternative phrasing that makes it clearer? Thanks, Sid