Hi, On Tue, Aug 08 2023, Richard Biener via Gcc-patches wrote: > 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 ;) >
If anyone is interested in scoping this and then mentoring this as a Google Summer of Code project this year then now is the right time to speak up! Thanks, Martin
