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.
Thanks,
Sid
