From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 0520E385803B for ; Tue, 2 Aug 2022 20:36:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0520E385803B Received: by mail-ej1-x631.google.com with SMTP id j8so2716506ejx.9 for ; Tue, 02 Aug 2022 13:36:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=0hLaQuVEEKe4vraqyu2IENFehTALFwL7DvvbyRDOq8w=; b=lyN0bk47jX/KtnQb0Y5nFtKyIDo3hqkz58Zgn8L1OMELDBuF585x8whTORi6CQxENZ JzLVWSUh3IlI6lkjnIrU5ZdBsoCPeN7SZ48gI4QBqJF7ohXSfENounAPSkOACy1OxLjR wqXa74eT9F9xEWMKLqILyVwDHtMUbJ7Aur+zNWPLW1huTL0VGWwtXnpJmCAPvIOxX8cK XbmVGclEtPJ4ALQK6wpTyYDlp5uAYJrWopsp7HGTSpYkH13hvBAkdFQkbNOU9sNN0EIj eMF1dQ/PD2SVWyVISXKCrDinXUl3tuc0DuwWmf3a5MLw0jGOR5cGd10Q8AEZ7xODh/zN CxFg== X-Gm-Message-State: ACgBeo06wp5KSC59Q3iOL6DWHpmESLXICJQjkZNbhGM7FsRrV/deQSTf TumgB5Y8o7v8YYu5FQOTrmoh2Jpb1v0WlU0DjbIVRG6N8oU= X-Google-Smtp-Source: AA6agR7o1rc1oz3yYMxbj+Op5g6xr+OKtez6C06WAy8ZDtoaL4/a/d19yMaVFU9VrrKoawThO//bWxD/w2UwdeYyaUY= X-Received: by 2002:a17:907:a057:b0:730:a2d8:d5ac with SMTP id gz23-20020a170907a05700b00730a2d8d5acmr3115397ejc.764.1659472576544; Tue, 02 Aug 2022 13:36:16 -0700 (PDT) MIME-Version: 1.0 References: <7e442ae6d3be28043d3c3ecd8a66af011b8dd573.camel@klomp.org> <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org> In-Reply-To: From: Daniel Thornburgh Date: Tue, 2 Aug 2022 13:36:05 -0700 Message-ID: Subject: Re: debuginfod Credential Helper RFC To: Mark Wielaard Cc: elfutils-devel@sourceware.org X-Spam-Status: No, score=-17.0 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HK_OBFDOM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2022 20:36:20 -0000 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=. 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 wrote: > On Fri, Jul 29, 2022 at 11:58 AM Mark Wielaard 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