From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 7705E3857352 for ; Fri, 29 Jul 2022 21:08:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7705E3857352 Received: by mail-ej1-x62c.google.com with SMTP id mf4so10557559ejc.3 for ; Fri, 29 Jul 2022 14:08:25 -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=+7oYwwofndWeQL1c9VVSy0LqeoX8IFKDrI9dOQt3Bb0=; b=cdqyXPvWiFJEp2I7HxtIXq7DaQ85kHICqXFzTpZbO3G6OdVQxSoxYAs90eLSM05LTj kLm8SV207AsNEEgcSxLjDFDJEStSLVRtaXPSe234t1lVqLxp1jr/QyBmAIzgShHKyt2W 6S6B98zakZafhYTeTLAOR8+jARotobkZNRja/3FUk9AxFcO2WIcwVB3EGS4ivYZNa13U 670+OhrRHpl9TBmVLkyOGFFsEpwNst7Q5VEhxHaJYr5oGm3eq+/bBaIJR/FesSW2XGge lj+HCPG2GARiMwlkmqqL/Y6ijd/EgdnUtW+SdXUQaKenV126osVr3DZS0hWXWJitWFIO baGQ== X-Gm-Message-State: AJIora9NklbwvIeT5ggVBDfhoFRHfR900aQmJ4lS5ioB2VO8Pbzs7wAR sUzV+XGxwIytMOuvhiI7LK6H+hSrEsz9wFW4Rzp9w0TiytFZig== X-Google-Smtp-Source: AGRyM1u/+iy6OhVJ2JVaClVOh4p9lQE3xkFd/GrQDBNl7CRLmaPsg7EeK7WQlYt2Pu1IFuioZGZdso5vh2fgDWleUe0= X-Received: by 2002:a17:907:a05c:b0:72b:347b:4f59 with SMTP id gz28-20020a170907a05c00b0072b347b4f59mr4135707ejc.764.1659128903918; Fri, 29 Jul 2022 14:08:23 -0700 (PDT) MIME-Version: 1.0 References: <7e442ae6d3be28043d3c3ecd8a66af011b8dd573.camel@klomp.org> <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org> In-Reply-To: <259802b4c23d488bbd68a5f50898f44e4258c530.camel@klomp.org> From: Daniel Thornburgh Date: Fri, 29 Jul 2022 14:08:12 -0700 Message-ID: Subject: Re: debuginfod Credential Helper RFC To: Mark Wielaard Cc: elfutils-devel@sourceware.org X-Spam-Status: No, score=-17.1 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: Fri, 29 Jul 2022 21:08:27 -0000 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