RFC: Adding a SECURITY.md document to the Binutils

[Jan Beulich]

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