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

["Frank Ch. Eigler" <fche@elastic.org>]

Hi, Mark -


> > - 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.


> 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.


> 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).


> [...]
> 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

> Also is this all rpm/koji specific? Or do other distros also use ima
> signatures, but encode/store them differently?

As far as I know, Fedora/RHEL are the first.  Yeah it's all
package/style specific.


> [...]
> We now also have a fish profile.

I'm afraid I don't speak fish. :-)


> > +debuginfod_ima_verification_enabled="no"
> > +if test "$enable_ima_verification" = "xrpmimaevmcrypto"; then
> > +  debuginfod_ima_verification_enabled="yes"
> > +  default_ima_cert_path=`eval echo "/etc/keys/ima:/etc/pki/rpm-ima:$sysconfdir/debuginfod/ima-certs"` # expand $prefix too
> > +  AC_DEFINE([ENABLE_IMA_VERIFICATION], [1], [Define if the required ima verification libraries are available])
> > +  AC_DEFINE_UNQUOTED(DEBUGINFOD_IMA_CERT_PATH_DEFAULT, "$default_ima_cert_path", [Default IMA certificate path])
> > +fi
> > +AM_CONDITIONAL([ENABLE_IMA_VERIFICATION],[test "$enable_ima_verification" = "xrpmimaevmcrypto"])
> > +
> 
> Not all these are needed anymore now are they?
> [...]

The elaborate default_ima_cert_path?  Yeah probably not, just force
Fedora etc. to use the configure parameter.  The AM_CONDITIONAL
"xrpmimaevmcrypto" part?  Yeah we need those.  (The iamevm part
is just for the headers.)

At some point, I'd like to reformat the debuginfod code base, it's
become a bit of a mishmash.  Separate commit later, I guess?


- FChE