From: Jan Beulich <jbeulich@suse.com>
To: Nick Clifton <nickc@redhat.com>
Cc: siddhesh@gotplt.org, "gdb@sourceware.org" <gdb@sourceware.org>,
Binutils <binutils@sourceware.org>
Subject: Re: RFC: Adding a SECURITY.md document to the Binutils
Date: Sat, 8 Apr 2023 08:30:27 +0200 [thread overview]
Message-ID: <68586aaa-f669-0045-d2b9-28f673362b66@suse.com> (raw)
In-Reply-To: <1c38b926-e003-0e21-e7f1-3d5dbec2aabf@redhat.com>
On 07.04.2023 10: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.
>
> Reporting private security bugs
> ===============================
>
> *All bugs reported in the Binutils Bugzilla are public.*
>
> In order to report a private security bug that is not immediately
> public, please contact one of the downstream distributions with
> security teams. The follow teams have volunteered to handle such
> bugs:
>
> Debian: security@debian.org
> Red Hat: secalert@redhat.com
> SUSE: security@suse.de
>
> Please report the bug to just one of these teams. It will be shared
> with other teams as necessary.
>
> The team contacted will take care of details such as vulnerability
> rating and CVE assignment (http://cve.mitre.org/about/). It is likely
> that the team will ask to file a public bug because the issue is
> sufficiently minor and does not warrant an embargo. An embargo is not
> a requirement for being credited with the discovery of a security
> vulnerability.
>
> Reporting public security bugs
> ==============================
>
> It is expected that critical security bugs will be rare, and that most
> security bugs can be reported in Binutils Bugzilla system, thus making
> them public immediately. The system can be found here:
>
> https://sourceware.org/bugzilla/
>
> ----------------------------------------------------------------------
>
> Thoughts ? Comments ?
Making aspects like this explicit (and easily findable) is certainly a good
thing imo.
Jan
next prev parent reply other threads:[~2023-04-08 6:30 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 8:42 Nick Clifton
2023-04-07 10:36 ` Eli Zaretskii
2023-04-11 13:29 ` Nick Clifton
2023-04-11 14:23 ` Simon Marchi
2023-04-11 15:00 ` Eli Zaretskii
2023-04-11 16:22 ` Nick Clifton
2023-04-11 16:32 ` Matt Rice
2023-04-11 18:18 ` J.W. Jagersma
2023-04-12 8:43 ` Nick Clifton
2023-04-08 6:30 ` Jan Beulich [this message]
2023-04-10 18:30 ` John Baldwin
2023-04-20 15:56 ` Nick Clifton
2023-04-11 19:45 ` Ian Lance Taylor
2023-04-12 16:02 ` Richard Earnshaw
2023-04-12 16:26 ` Siddhesh Poyarekar
2023-04-12 16:52 ` Richard Earnshaw
2023-04-12 16:58 ` Paul Koning
2023-04-12 17:10 ` Siddhesh Poyarekar
2023-04-13 3:51 ` Alan Modra
2023-04-13 4:25 ` Siddhesh Poyarekar
2023-04-13 5:16 ` Alan Modra
2023-04-13 12:00 ` Siddhesh Poyarekar
2023-04-13 10:25 ` Richard Earnshaw
2023-04-13 11:53 ` Siddhesh Poyarekar
2023-04-13 12:37 ` Richard Earnshaw
2023-04-13 12:54 ` Siddhesh Poyarekar
2023-04-13 13:11 ` Richard Earnshaw
2023-04-13 13:35 ` Siddhesh Poyarekar
2023-04-13 13:40 ` Richard Earnshaw
2023-04-13 13:56 ` Siddhesh Poyarekar
2023-04-13 14:50 ` Richard Earnshaw
2023-04-13 15:02 ` Siddhesh Poyarekar
2023-04-13 15:05 ` Richard Earnshaw
2023-04-13 16:42 ` Siddhesh Poyarekar
2023-04-14 9:52 ` Richard Earnshaw
2023-04-14 12:43 ` Siddhesh Poyarekar
2023-04-14 12:49 ` Richard Earnshaw
2023-04-14 13:13 ` Siddhesh Poyarekar
2023-04-13 15:08 ` Paul Koning
2023-04-13 16:02 ` Siddhesh Poyarekar
2023-04-13 16:49 ` Paul Koning
2023-04-13 17:00 ` Siddhesh Poyarekar
2023-04-13 17:05 ` Paul Koning
2023-04-13 17:29 ` Siddhesh Poyarekar
2023-04-13 17:37 ` Paul Koning
2023-04-13 18:16 ` Siddhesh Poyarekar
2023-04-14 17:37 ` Ian Lance Taylor
2023-04-14 18:27 ` Siddhesh Poyarekar
2023-04-14 20:46 ` Ian Lance Taylor
2023-04-14 21:24 ` Siddhesh Poyarekar
2023-04-17 15:31 ` Michael Matz
2023-04-17 19:55 ` Ian Lance Taylor
2023-04-14 19:45 ` DJ Delorie
2023-04-14 20:49 ` Ian Lance Taylor
2023-04-15 6:41 ` Xi Ruoyao
2023-04-13 16:06 ` Richard Earnshaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=68586aaa-f669-0045-d2b9-28f673362b66@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=nickc@redhat.com \
--cc=siddhesh@gotplt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).