Re: [RFC] Adding a SECURITY policy for GDB

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org, siddhesh@redhat.com, kevinb@redhat.com,
>  simark@simark.ca, felix.willgerodt@intel.com, paulkoning@comcast.net
> Date: Sun, 04 Feb 2024 15:32:58 +0000
> 
> >>   Any bugs in GDB that result in execution of the program being
> >>   debugged without a user issued GDB command triggering execution
> >                             ^^^^^^
> > "issuing"
> >
> >>   (either from the GDB command line, a GDB configuration file, or from
> >>   the GDB prompt) are considered security bugs.
> >
> > Is any execution of the program triggered by starting GDB considered
> > "a command issued by the user"?  IOW, are we sure GDB will never cause
> > some program code to be executed just as result of the user saying
> >
> >   $ gdb ./program
> >
> > ?  The above text seems to assume that any such execution at startup
> > must be the result of some command-line argument or some configuration
> > file, but is that 110% certain, and are we sure this will _never_
> > change?
> 
> Am I 110% certain?  No.  I'm never going to claim that level of
> certainty on a topic.  But I am 99% certain.
> 
> Am I sure this will _never change?  No.  But that's OK.
> 
> This document is about writing down an agreed project position on this
> behaviour today.
> 
> If tomorrow someone wants to propose a patch where 'gdb ./prog' would
> automatically run './prog' then they are welcome to do so.  But part of
> that patch would require updating the SECURITY.txt document, and
> hopefully, by touching the SECURITY.txt document, this would trigger a
> conversation about whether we actually wanted to make that change.
> 
> But that doesn't mean this document cannot be changed.
> 
> FYI, right now, if someone did propose such a patch, I would be against
> it being merged due to the possible security implications.

What bothered me here is that when you say "gdb ./program", GDB can do
two things which constitute code execution:

  . run some startup code in the program, for example, load some
    shared libraries, which could trigger execution of some code in
    those libraries, or
  . process various init files, which could invoke code in
    Python/Guile, or call functions inside the debuggee

The second item actually happens when you say "gdb ./emacs" in the src
directory of an Emacs source tree, because there's a .gdbinit file
that which can call functions inside the executable and/or run Python
code.  Are these cases relevant to this part of the policy?