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 <dth...@google.com> wrote: > On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard <m...@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:p...@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 | dth...@google.com > > -- Daniel Thornburgh | dth...@google.com
