Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Xi Ruoyao via Gdb <gdb@sourceware.org>
To: Ian Lance Taylor <iant@google.com>, DJ Delorie <dj@redhat.com>
Cc: binutils@sourceware.org, gdb@sourceware.org
Subject: Re: RFC: Adding a SECURITY.md document to the Binutils
Date: Sat, 15 Apr 2023 14:41:19 +0800	[thread overview]
Message-ID: <463988a9ddeb985307af5dd8bae1e008b7f31195.camel@xry111.site> (raw)
In-Reply-To: <CAKOQZ8wzHN+2RDXnOVtFyBmtSYhqD5HSC2dNi1PacbVKcgOD5g@mail.gmail.com>

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

  reply	other threads:[~2023-04-15  6:41 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-07  8:42 Nick Clifton via Gdb
2023-04-07 10:36 ` Eli Zaretskii via Gdb
2023-04-11 13:29   ` Nick Clifton via Gdb
2023-04-11 14:23     ` Simon Marchi via Gdb
2023-04-11 15:00       ` Eli Zaretskii via Gdb
2023-04-11 16:22         ` Nick Clifton via Gdb
2023-04-11 16:32           ` Matt Rice via Gdb
2023-04-11 18:18         ` J.W. Jagersma via Gdb
2023-04-12  8:43           ` Nick Clifton via Gdb
2023-04-08  6:30 ` Jan Beulich via Gdb
2023-04-10 18:30 ` John Baldwin
2023-04-20 15:56   ` Nick Clifton via Gdb
2023-04-11 19:45 ` Ian Lance Taylor via Gdb
2023-04-12 16:02 ` Richard Earnshaw via Gdb
2023-04-12 16:26   ` Siddhesh Poyarekar
2023-04-12 16:52     ` Richard Earnshaw via Gdb
2023-04-12 16:58       ` Paul Koning via Gdb
2023-04-12 17:10       ` Siddhesh Poyarekar
2023-04-13  3:51         ` Alan Modra via Gdb
2023-04-13  4:25           ` Siddhesh Poyarekar
2023-04-13  5:16             ` Alan Modra via Gdb
2023-04-13 12:00               ` Siddhesh Poyarekar
2023-04-13 10:25         ` Richard Earnshaw via Gdb
2023-04-13 11:53           ` Siddhesh Poyarekar
2023-04-13 12:37             ` Richard Earnshaw via Gdb
2023-04-13 12:54               ` Siddhesh Poyarekar
2023-04-13 13:11                 ` Richard Earnshaw via Gdb
2023-04-13 13:35                   ` Siddhesh Poyarekar
2023-04-13 13:40                     ` Richard Earnshaw via Gdb
2023-04-13 13:56                       ` Siddhesh Poyarekar
2023-04-13 14:50                         ` Richard Earnshaw via Gdb
2023-04-13 15:02                           ` Siddhesh Poyarekar
2023-04-13 15:05                             ` Richard Earnshaw via Gdb
2023-04-13 16:42                               ` Siddhesh Poyarekar
2023-04-14  9:52                                 ` Richard Earnshaw via Gdb
2023-04-14 12:43                                   ` Siddhesh Poyarekar
2023-04-14 12:49                                     ` Richard Earnshaw via Gdb
2023-04-14 13:13                                       ` Siddhesh Poyarekar
2023-04-13 15:08                             ` Paul Koning via Gdb
2023-04-13 16:02                               ` Siddhesh Poyarekar
2023-04-13 16:49                                 ` Paul Koning via Gdb
2023-04-13 17:00                                   ` Siddhesh Poyarekar
2023-04-13 17:05                                     ` Paul Koning via Gdb
2023-04-13 17:29                                       ` Siddhesh Poyarekar
2023-04-13 17:37                                         ` Paul Koning via Gdb
2023-04-13 18:16                                           ` Siddhesh Poyarekar
2023-04-14 17:37                                     ` Ian Lance Taylor via Gdb
2023-04-14 18:27                                       ` Siddhesh Poyarekar
2023-04-14 20:46                                         ` Ian Lance Taylor via Gdb
2023-04-14 21:24                                           ` Siddhesh Poyarekar
2023-04-17 15:31                                           ` Michael Matz via Gdb
2023-04-17 19:55                                             ` Ian Lance Taylor via Gdb
2023-04-14 19:45                                       ` DJ Delorie via Gdb
2023-04-14 20:49                                         ` Ian Lance Taylor via Gdb
2023-04-15  6:41                                           ` Xi Ruoyao via Gdb [this message]
2023-04-13 16:06                               ` Richard Earnshaw via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=463988a9ddeb985307af5dd8bae1e008b7f31195.camel@xry111.site \
    --to=gdb@sourceware.org \
    --cc=binutils@sourceware.org \
    --cc=dj@redhat.com \
    --cc=iant@google.com \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox