RFC: Adding a SECURITY.md document to the Binutils

[Xi Ruoyao]

On Fri, 2023-04-14 at 13:49 -0700, Ian Lance Taylor via Binutils wrote:
> On Fri, Apr 14, 2023 at 12:45 PM DJ Delorie <dj@redhat.com> wrote:
> > 
> > Ian Lance Taylor via Gdb <gdb@sourceware.org> writes:
> > > Compilers and linkers must behave in a reasonable manner when given
> > > untrusted input.
> > 
> > Are we confusing trusted with well-behaved?  I mean, if I download a
> > source tree from the FSF's git server, I trust it, but it may still be
> > ill-behaved.  Meanwhile, sources from a public mailing list may be
> > well-behaved but not trusted.
> > 
> > I'm only posting this because Carlos and I had long discussions about
> > this before we set up the glibc pre-commit CI.  This process takes
> > random patches from the public glibc mailing list, and builds them.
> > WHOA!  That's dangerous!  Yes.  The patches may produce well-defined
> > code, but are not trusted.  Those builds run in a tight sandbox to
> > mitigate any attack attempts.  Security here is outside the scope of the
> > build tools.  I don't expect gcc to scan for viruses or prevent people
> > from doing "#include </etc/passwd>".
> 
> I agree that GCC does not have to scan for viruses or strange #include
> statements.
> 
> I am saying that you should not need to set up a sandbox merely to
> build code.  Clearly if you want to execute untrusted code, some sort
> of sandbox is a minimal requirement.  I'm only talking about building
> code (and, for objdump and friends, inspecting code).

In practice:

1. At least we need a resource limit on the building process or a simple
"int x[1 << 30] = {1,};" may blow up the server.  We cannot just make
GCC reject "int x[1 << 30] = {1,};" because it may be perfectly legal
(though bad) in other use cases.
2. For "#include </etc/passwd>", the risk is the passwd entries may be
contained in the error message outputted by the compiler.  It happens at
build time, not runtime.  It does not make too much sense to make GCC
"don't output any error message if the error is in some sensitive file"
because GCC cannot know a list of sensitive files on the system.  And it
also does not make too much sense to set an automatic build job w/o
providing the compiler error message.

So sandboxing is the only viable solution for the automatic build jobs
even if these jobs won't run any produced binaries.  If you are building
normally (manually), things may be different though.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University