RFC: Adding a SECURITY.md document to the Binutils

Nick Clifton via Gdb
2023-04-07T08:44:03Z

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 ?

Cheers
Nick