Re: [rfc] [patch] PR28204: debuginfod ima signature verification

[Mark Wielaard <mark@klomp.org>]

Hi Frank,

On Wed, Apr 10, 2024 at 05:01:36PM -0400, Frank Ch. Eigler wrote:
> > > - to drop "permissive" mode
> > 
> > We discussed a bit on irc about "wording". But I think it isn't really
> > how it is worded, but that there is just different features. What is
> > called "enforcing" is an authenticity scheme. While "permissive" is
> > more like an (optional) error-detecting mode. IMHO it makes sense to
> > simply separate those.
> 
> For the record, on IRC, I presented these two additional arguments:
> 
> 
>     in the case of federated debuginfod servers, such as
>     debuginfod.elfutils.org, a user is stuck with "ignore" mode
>     operation, because not all upstream servers will have ima
>     signatures to pass.  this sacrifices all possible assurance that
>     could come from the federated server relaying ima signatures from
>     those servers that have them
> 
>     even in non-federated cases such as fedoraproject.org, the ideal
>     case for "enforcing" mode as a default, it will fail the moment
>     the user happens to try to debug some pre-fedora-38 binary that
>     may be sitting on the system --- because those rpms just don't
>     have signatures available at all
> 
>     for both these scenarios, the original "permissive" mode would be
>     suitable
> 
> 
> IOW, without a "permissive" mode being available at all, we could not
> ask users to enable this new code at all for our own federated
> servers, nor even for fedora.  That's because no server can guarantee
> the availability of signatures for all content they can serve.

I don't understand why you say we cannot ask users to enable the ima
checking code. Isn't the goal to make sure that the user only gets
ima-signed/verified files for the distro they are debugging/analyzing
on? Especially if a server can also provide non-verifiable files, then
you would want to have strict checking to make sure.

> > That way you don't have a authentication scheme that is easily
> > defeated (when put in "permissive" mode).
> 
> This "easily defeated" theory needs a threat model.  It sounds like
> you are thinking of
> - an evil debuginfod instance that
> - you trust enough to list in DEBUGINFOD_URLS
> - but not enough to label it with "ima:enforcing"
> - which may strip the X-DEBUGINFOD-FILE-SIGNATURE header" en route
> then yeah, but sounds far-fetched rather than easy.

I think I simply don't understand what the thread model is that
ima:permissive guards against. It seems not to protect against the
main thing you want to do ima checking for. You only want
debuginfod-client to provide files that are signed and can be
verified.

> > And you can implement a simpler error-detection mode that can work
> > in more cases (by using the executable .gnu_debuglink CRC)
> 
> No, we already know that this is incapable of checking e.g. source
> files.  And there is no separate CRC for executables vs. debuginfo
> files.  And note that this provides zero protection in the same threat
> model above (as the CRC field could be MITM'd).

Sure. I guess if you don't enforce ima checking you can just rely on
https. And it is kind of the point that this is similar to the threat
model that "permissive" guards against (random, bit flipping,
accidential replacement of files). Relying on https and CRC checking
seems simpler to understand for that. But you are right that there
isn't really anyhing for the main executables. For the source files
you could check the lenght and time stamps (or the MD5 sums if added
by the DWARF producer).

> > [...]
> > One "big picture" question is whether this should be a per server URL
> > policy or something that is enabled/disabled for all server URLs?
> > That makes it less "flexible" but should simplify things a bit for the
> > user (and the server urls parsing).
> 
> Blame some guy named Mark for getting Ryan to build that out last year. :-)
> 
> https://sourceware.org/pipermail/elfutils-devel/2023q3/006299.html

Sorry. I see back then I also didn't get use case for the "permissive"
policy. But yes, it might have been a mistake to suggest different
policies per URL/server.

Cheers,

Mark