[Bug debuginfod/27758] New: security idea: DEBUGINFOD_VERIFY mode

[Bug debuginfod/27758] New: security idea: DEBUGINFOD_VERIFY mode

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

            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 trustworthy. 
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 not
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 verification
of cached content, without having to fully download again.  Here's one possible
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 only
with a HEAD query, otherwise same webapi
- the server code, upon seeing the HEAD query, will return additional response
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 don'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=enforcing or =permissive or (none) differently for root
and/or less privileged users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

[zbyszek at in dot waw.pl]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

Zbigniew Jędrzejewski-Szmek <zbyszek at in dot waw.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zbyszek at in dot waw.pl

--- Comment #1 from Zbigniew Jędrzejewski-Szmek <zbyszek at in dot waw.pl> ---
I don't think this protection is particularly interesting. Normal file system
permissions should be used to safeguard any files in the home directory. I
don't see a reason to try to add a verification layer on top. And if it was
added, it cannot be effective anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
Yeah.  It may comfort those who are worried about the integrity of their
previously downloaded cached files, but is not robust against local attacker
who currently has control over the filesystem or processes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

[vt at altlinux dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

Vitaly Chikunov <vt at altlinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vt at altlinux dot org

--- Comment #3 from Vitaly Chikunov <vt at altlinux dot org> ---
Instead of `X-Debuginfod-Hash` you can use `ETag` where you can put anything
including sha256 (can be prescribed in webapi description), then GET request
with `If-None-Match` + tag value (which is a hash) will return just 304 if the
hash is not changed. So HEAD request is not needed too.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
And it should be possible to use the Content-Length header to verify that the
data does not have an excessive size (something that is not possible with just
the hash itself).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

--- Comment #5 from Frank Ch. Eigler <fche at redhat dot com> ---
(In reply to Vitaly Chikunov from comment #3)
> Instead of `X-Debuginfod-Hash` you can use `ETag` where you can put anything
> including sha256 (can be prescribed in webapi description), then GET request
> with `If-None-Match` + tag value (which is a hash) will return just 304 if
> the hash is not changed. So HEAD request is not needed too.

That's a good idea, except in the case of an older [current] debuginfod that
doesn't understand If-None-Match, and would just resend the entire content
every time.  But at least it's not a security problem, just a performance one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27758] security idea: DEBUGINFOD_VERIFY mode

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Frank Ch. Eigler <fche at redhat dot com> ---
putting idea on ice

-- 
You are receiving this mail because:
You are on the CC list for the bug.