Re: RFC: Adding a SECURITY.md document to the Binutils

Jan Beulich via Gdb
2023-04-08T06:31:07Z

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