On Tue, Aug 8, 2023 at 2:33 PM Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > > On 2023-08-08 04:16, Richard Biener wrote: > > 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. > > Ack, I'd expect libstdc++ and libgcc to be aligned with glibc's > policies. libiberty and others on the other hand, would probably be > more suitably aligned with binutils libbfd, where we assume trusted input. > > >> 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. > > It's not a bad idea, but it ends up giving legitimizing running the > compiler as root, pushing the responsibility of privilege management to > the driver. How about rejecting invocation as root altogether by > default, bypassed with a --run-as-root flag instead? > > I've also been thinking about a --sandbox flag that isolates the build > process (for gcc as well as binutils) into a separate namespace so that > it's usable in a restricted mode on untrusted sources without exposing > the rest of the system to it.
There's probably external tools to do this, not sure if we should replicate things in the driver for this. But sure, I think the driver is the proper point to address any of such issues - iff we want to address them at all. Maybe a nice little google summer-of-code project ;) Richard. > > Thanks, > Sid
