From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 232DF383B423; Tue, 20 Apr 2021 15:22:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 232DF383B423 From: "fche at redhat dot com" To: elfutils-devel@sourceware.org Subject: [Bug debuginfod/27758] New: security idea: DEBUGINFOD_VERIFY mode Date: Tue, 20 Apr 2021 15:22:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: debuginfod X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fche at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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, 20 Apr 2021 15:22:41 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27758 Bug ID: 27758 Summary: security idea: DEBUGINFOD_VERIFY mode Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Reasonable concerns have been raised about whether a debuginfod client has = any way of verifying that artifacts downloaded are unmodified / still trustwort= hy.=20 This is a good question because any package-level signature protection is stripped at the server, when we serve constituent files in isolation. As transport over HTTPS protects the content, we can safely assume that immediately during/after the download, the content will be fine. However, = what of cached files? What if some program changes the cache contents sometime between download and a much later reuse? (Note that this threat model is n= ot that serious, since any tool that could modify cache contents can probably = also modify dot files etc., and take over the user's account.) But anyway, as a trust/comfort measure, we could provide limited verificati= on of cached content, without having to fully download again. Here's one poss= ible way: - all this being conditional on a client-side environment variable like $DEBUGINFOD_VERIFY being set - in the -client.c code, during a find operation, if there is a cache hit, = the client will STILL make a connection to the upstream $DEBUGINFOD_URLS, but o= nly with a HEAD query, otherwise same webapi - the server code, upon seeing the HEAD query, will return additional respo= nse headers - one of these response headers will be X-Debuginfod-Hash: XYZXYZXYZ, which would be some securish hash of the content, probably sha256 or such - the server will compute / cache this hash in a new sqlite table, akin to = the buildids9_file_mtime_scanned, for each file over time, subject to grooming = as usual - how federated servers do this w.r.t serving from their own cache: TBD - the client will look for this response header from all servers that return 200 - if no server returns this header (maybe because it's just old, or they do= n't happen to have the hash cached or such), and if $DEBUGINFOD_VERIFY value is "permissive", result -> PASS, return - the client will pick ANY or ALL (maybe depending on bug #25607 policy?) - the client will compute the same hash function on the cached content, and compare - if the local hash mismatches the server-provided hash, warn via $DEBUGINFOD_VERBOSE, delete local cached object, perform full download - otherwise: result -> PASS, return In the elfutils profile.d/debuginfod.* files, distro policy could set $DEBUGINFOD_VERIFY=3Denforcing or =3Dpermissive or (none) differently for r= oot and/or less privileged users. --=20 You are receiving this mail because: You are on the CC list for the bug.=