Re: [RFC] Adding a SECURITY policy for GDB

[Andrew Burgess <aburgess@redhat.com>]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew> Apologies for taking so long to get a second version of this document
> Andrew> prepared.  I've been through several iterations of this text since I
> Andrew> last posted trying to get something semi-reasonable... It would be great
> Andrew> to get your feedback on this new text.
>
> Thank you for doing this.
>
> Andrew>     So, instead, I've just given up on that.  I think Simon, Paul, and
> Andrew>     Felix should find (at least this part of) the new text satisfactory;
> Andrew>     loading a binary, but not executing it, should be safe to do, and if
> Andrew>     that's not the case, then this is a security issue.
>
> I think this is what users expect, but I don't think this is at all in
> line with what we can promise.  We couldn't get consensus to deprecate
> the stabs reader last year, but at the same time, nobody works on the
> existing fuzzer bugs that have been reported against it (or was it
> mdebugread?) ... the point being that there's a lot of
> dead-but-vulnerable code.
>
> For the DWARF reader, this safety might be attainable, though given the
> large number of DWARF scenarios, I am skeptical.  In any case, this
> promise definitely doesn't describe the situation *today*, where nobody
> has seriously tried fuzzing, or even really looking through the more
> obvious possible buffer overruns.
>
> To be clear, I'm not at all opposed to someone fixing fuzzer bugs.  It's
> clear to me that it ought to be done, even if it comes at some cost.
>
> Perhaps this is covered by the section recommending sandboxing.

Thanks for your thoughts on this.  What you've said is similar to
discussions I've had within Red Hat on this topic.

On one hand some argue the security policy should reflect the current
state of GDB, and bugs that are found in areas of GDB which are known to
be, maybe, not so robust, should not be classified as security bugs.
The interest of folk in this group are mostly about reducing the number
of security issues that are reported, so they'd like to see an upstream
security policy which lets bugs reported as "security" be reclassified
as "normal" upstream bugs.

Then there's the view which was reflected (I think) in the initial
feedback to my V1 proposal, and which is where I now sit.  The security
policy should be aspirational, lay out how we'd like things to be, and
then, in theory, we can work towards that as a goal.

But reading what you write, I think maybe there's a third position which
sits somewhere between these two, and you're right that I do touch on
this third position when I discuss sandboxing, but maybe I don't stress
this enough?  I should probably lay out where we'd like GDB to be, but
then be more open and realistic about where GDB actually is.

I think we're all agreeing that a user should be able to examine
(without running) an untrusted binary and have this be risk free.  But
as you point out, and I don't think anyone will disagree with, right now
that isn't really a safe thing to do, and really folk shouldn't be doing
that.

I also have some notes from Eli to fold in, so I'll take another pass at
this next week and try to come up with a V4 which covers these ideas.

Thanks for your feedback,
Andrew

>
> Andrew> One last thing, while writing this, I did wonder if this text would be
> Andrew> better moved into the GDB manual, and the gdb/SECURITY.txt document
> Andrew> should just say "See the GDB manual", but I figure that's a problem for
> Andrew> future me, for now I just need to find some words we can all agree on.
>
> I think this would be good.
>
> Tom