On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > FOSS Best Practices recommends that projects have an official Security > policy stated in a SECURITY.md or SECURITY.txt file at the root of the > repository. GLIBC and Binutils have added such documents. > > Appended is a prototype for a Security policy file for GCC based on the > Binutils document because GCC seems to have more affinity with Binutils as > a tool. Do the runtime libraries distributed with GCC, especially libgcc, > require additional security policies? > > [ ] Is it appropriate to use the Binutils SECURITY.txt as the starting > point or should GCC use GLIBC SECURITY.md as the starting point for the GCC > Security policy? > > [ ] Does GCC, or some components of GCC, require additional care because of > runtime libraries like libgcc and libstdc++, and because of gcov and > profile-directed feedback?
I do think that the runtime libraries should at least be explicitly mentioned because they fall into the "generated output" category and bugs in the runtime are usually more severe as affecting a wider class of inputs. > Thoughts? > > Thanks, David > > GCC Security Process > ==================== > > What is a GCC security bug? > =========================== > > A security bug is one that threatens the security of a system or > network, or might compromise the security of data stored on it. > In the context of GCC there are two ways in which such > bugs might occur. In the first, the programs themselves might be > tricked into a direct compromise of security. In the second, the > tools might introduce a vulnerability in the generated output that > was not already present in the files used as input. > > 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 GCC (e.g., > gcc, g++, gfortran, gccgo, gccrs, gnat, cpp, gcov, etc.) and the > libraries that they use. > > Notes: > ====== > > None of the programs in GCC need elevated privileges to operate and > it is recommended that users do not use them from accounts where such > privileges are automatically available. I'll note that we could ourselves mitigate some of that by handling privileged invocation of the driver specially, dropping privs on exec of the sibling tools and possibly using temporary files or pipes to do the parts of the I/O that need to be privileged. > Reporting private security bugs > ======================== > > *All bugs reported in the GCC 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 following teams have volunteered to handle > such bugs: > > Debian: secur...@debian.org > Red Hat: secal...@redhat.com > SUSE: secur...@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 > ============================== Put this first, name it "Reporting security bugs" > It is expected that critical security bugs will be rare, and that most > security bugs can be reported in GCC, thus making > them public immediately. The system can be found here: > > https://gcc.gnu.org/bugzilla/
