RE: [RFC] Adding a SECURITY policy for GDB

["Willgerodt, Felix" <felix.willgerodt@intel.com>]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Freitag, 8. Dezember 2023 16:06
> To: gdb-patches@sourceware.org
> Cc: Siddhesh Poyarekar <siddhesh@redhat.com>; Kevin Buettner
> <kevinb@redhat.com>; Simon Marchi <simark@simark.ca>; Willgerodt, Felix
> <felix.willgerodt@intel.com>; Paul Koning <paulkoning@comcast.net>
> Subject: Re: [RFC] Adding a SECURITY policy for GDB
> 
> 
> Hello!
> 
> Apologies for taking so long to get a second version of this document
> prepared.  I've been through several iterations of this text since I
> last posted trying to get something semi-reasonable... It would be great
> to get your feedback on this new text.
> 
> This is basically a complete rewrite since V1, I'll try cover how this
> new text addresses the feedback on V1:
> 
>  1. A part of the original hope was that I could write some text that
>     would allow bugs triggered by just loading a binary into GDB (but not
>     running it) as non-security bugs.  Why?  Well, most of the bugs we
>     see in this area are from folk throwing fuzzed binaries at GDB,
>     raising a bug, and then raising a CVE on the back of that.  The
>     first part of this process is useful for sure.  The CVE part is just
>     a resource drain for downstream distributions.
> 
>     I did make several attempts to write some text that would classify
>     bugs in this way ... but, to be honest, after about my fourth
>     attempt, all I'd managed to do was convince myself that this was not
>     a good idea.
> 
>     So, instead, I've just given up on that.  I think Simon, Paul, and
>     Felix should find (at least this part of) the new text satisfactory;
>     loading a binary, but not executing it, should be safe to do, and if
>     that's not the case, then this is a security issue.
> 
>  2. As an aside, but not really relevant to the new text, given my
>     evolving position, I would say that I now disagree with the binutils
>     SECURITY position w.r.t. tools like objdump and readelf that Felix
>     mentioned.  I think it's not unreasonable that a user might run an
>     analysis tool on an untrusted binary, and if such a tool can be
>     tricked (via a bug) into executing code, even with the permissions
>     of the original user, then I would see this as a security risk.
> 
>  3. Kevin asked for discussion about running crash diagnostic tools that
>     wrap around GDB.  I believe this is covered by the new text which
>     discusses in more detail how to safely run against trusted vs
>     untrusted binaries.  Kevin: If you feel there are still things
>     missing that you'd like to see, then maybe you could suggest at
>     least some bullet points for what should be said, and I'll have a go
>     at fleshing it out.
> 
> One last thing, while writing this, I did wonder if this text would be
> better moved into the GDB manual, and the gdb/SECURITY.txt document
> should just say "See the GDB manual", but I figure that's a problem for
> future me, for now I just need to find some words we can all agree on.
> 
> Thanks,
> Andrew

Hi Andrew,

Thanks again for taking the time to write this! I think the new text is great
and I am in favor of it.

Regards,
Felix

 
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928