Re: debuginfod Credential Helper RFC

[Daniel Thornburgh <dthorn@google.com>]

So, I put together a design with this approach, and it passed a security
review, so the approach broadly seems to work for us.

It came up in review that it'd be considerably more usable to have the
environment variable point to a file: DEBUGINFOD_HEADERS_FILE=<file>. This
would avoid storing credentials in environment variables, and it would
allow you to set up the path to the header file in your shell config at the
beginning of a session.

Would this work for libdebuginfod? We'd also want to standardize on the
format of such a file; probably a newline-separated list of headers in the
format accepted by debuginfod_add_http_header()?

On Fri, Jul 29, 2022 at 2:08 PM Daniel Thornburgh <dthorn@google.com> wrote:

> On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard <mark@klomp.org> wrote:
>
>> I don't know how people "scope" this. But it feels a little paranoid to
>> restrict access to debuginfo and sources. So I wouldn't really mind
>> other users also having access.
>>
>> You don't even need a real httpd proxy, you could even run a federating
>> local debuginfod server that knows how to do authorization requests.
>>
> The only use I know of for a feature like this (which is our use case) is
> to allow debuginfod to work with closed source software. Even if most of
> the system is open source, there may be binary blobs where manufacturers
> may share source/debug info with developers under a restricted license that
> requires access control to the information.
>
>> > > Or by simply defining the base DEBUGINFOD_URL with
>> > > https://user:pass@debuginfod.example.com/ ?
>> > >
>> >
>> > The specific use case we had in mind uses OAuth2 bearer tokens, not
>> > username/password pairs. This is increasingly common for the sorts of
>> cloud
>> > hosting one might like to use for things like debug binaries.
>>
>> A bearer token is really just an Authorization header key with a random
>> string as value. We already have:
>>
>> /* Add an outgoing HTTP request  "Header: Value".  Copies string.  */
>> int debuginfod_add_http_header (debuginfod_client *client, const char*
>> header);
>>
>> So we could maybe have a DEBUGINFO_HEADERS environment variable that
>> then contains something like "Authorization: Bearer mF_9.B5f-4.1JqM"
>> Which would simply make sure debuginfod_add_http_header is called with
>> that value (or multiple if we can agree on a separator character).
>>
> That way you can run any program using libdebuginfod and get the
>> authorization for free by just running it something like:
>>
>> export DEBUGINFO_HEADERS="$(credential-helper $DEBUGINFOD_URLS)"
>> gdb --args ./hack frob frob
>>
>> Somewhat simplified, since it assumes you just have one DEBUGINFOD_URL
>> that needs the Authorization, but that seems fine, it seems an obscure
>> enough feature that it doesn't really matter if other servers get the
>> Authorization header too, they will just ignore it and don't even know
>> against what other server they could use the Bearer token.
>>
>
> Ah, I hadn't really looked much at libdebuginfod's interface yet, but
> that's very very interesting. Combining this with the idea above, you could
> write a nonce to a file only visible to the given user, then write an
> authorizing http proxy on localhost that would make sure the incoming http
> connection has the matching nonce. Then, the server could supply whatever
> credentials are necessary to any outbound servers it federates to. Then,
> you'd just need to pass the nonce in DEBUGINFOD_HEADERS and set
> DEBUGINFOD_URLS to the local server.
>
> I'll spend some time trying to prototype this and see if it works out like
> I think it would. It would be more work for integrators, but that's
> generally what I think you'd want for something that's arguably a pretty
> niche feature as far as things go, and a good reference implementation
> could also be built that supports credential helpers and could be extended
> with whatever access mechanisms you like.
>
>
>> Would any of the above work for your use case?
>>
>> Cheers,
>>
>> Mark
>>
>
>
> --
>
> Daniel Thornburgh | dthorn@google.com
>
>

-- 

Daniel Thornburgh | dthorn@google.com