Re: [PATCH] PR28204, debuginfod IMA

[Mark Wielaard <mark@klomp.org>]

Hi Frank,

On Tue, 2023-10-31 at 11:46 -0400, Frank Ch. Eigler wrote:
> > My point is really that posting with git format-patch or send-email
> > makes it possible for someone to simply use git am, b4 or git pw to try
> > out a patch. If the patch doesn't apply then that will be the first
> > review issue.
> 
> I see what you mean, but maybe that puts the cart ahead of the horse.
> What's desirable is easy access to a runnable version of the patch,
> not the choice of command line tooling to do that.  A published git
> branch containing the same patch is even simpler than using git
> am/b4/pw.  git is the most convenient transport protocol for patches.

Since we are discussing/reviewing patches on the mailinglist I think it
makes sense posting them in a form that makes them easy to apply. That
can be addition to some other way to also publish them.

> > I think my issue is really that it is unclear what "reassurances" we
> > are making. What is the threat-model? Permissive says to me that
> > although checks are done, they don't block receiving files. [...]
> 
> In the current version of the users/fche/try-bz28204 branch, this
> has been renamed "optimistic", and the man page blurb now says:
> 
>    \fIima:optimistic\fP Every downloaded file with a known-invalid
>    signature is rejected, protecting against some types of corruption.

I like this wording more. But maybe it would be helpful to split the
patch into one that implements ima:enforcing and another that adds the
ima:optimistic idea. That way we can more easily get the code in that
we seem to agree on. And it makes it more clear what extra code is
needed for the other policies.

> > > They already make the decision whom they download debuginfo from.
> > > That's literally what setting $DEBUGINFOD_URLS is.  The scenario
> > > you're describing would be trusting a server enough to supply content,
> > > trusting our code to fetch & check that content, but not trusting us
> > > to redistribute public certificates for the servers.
> > 
> > The user shouldn't trust a middle-person. Unless we are signing those
> > files we shouldn't distribute the certificates are being trustable
> > imho.
> 
> We sign our elfutils releases, and packagers often sign their builds
> of our releases, which users can verify.

Right, but those are files we write and distribute. These are
certificates that other use to sign files they distribute.

> > So you propose we setup a curating process to decide which certificates
> > to include? 
> 
> Sure.  We already curate a set of debuginfod servers.

You mean the list of servers that https://debuginfod.elfutils.org/
federates? I don't mind that server also maintaining a list of ima
certs for those servers. But make sure the distros actually want
someone else to redistribute their certificates. I can imagine distros
wanting people to get their certificates from them directly.

I don't think we should redistribute them as part of the main elfutils
package though.

> 
> > > > [...]
> > > > > Not sure, but this is how libimaevm.c similar code does it.  I assume
> > > > > the first byte of the signature is something else.
> > > > > (https://git.code.sf.net/p/linux-ima/ima-evm-utils)
> > > > 
> > > > ewww. Does this pass ubsan (--enable-sanitize-undefined)?  
> > > 
> > > Haven't tried but it passes valgrind.
> > 
> > valgrind doesn't check for undefined behavior or type alignment
> > requirements.
> 
> An elfutils build with --enable-sanitize-undefined had no complaints.

Good. I still don't like the code, but at least it seems the compiler
sees it as something that should work.

> > One other issue I noticed is that it seems to be distributed under
> > GPLv2-only. Which seems to mean that anything based on it should also
> > be distributed under GPLv2-only, which would include libdebuginfod. Is
> > there code we can rely on that is GPLv2+ and LGPLv3+ compatible?
> 
> Ugh.  I don't know of an alternative.  There isn't an equivalent
> command line wrapping of the library either (with respect to
> certificate searching) that we could fork out to.  (OTOH, GPLv2 is
> compatible with GPLv2+.)

But GPLv2-only is not compatible with GPLv3 which is used by e.g. gdb.
This is a bit of a pickle :{

> > > openssl's initialization is fine & thread-safe in practice, despite
> > > the documentation's warnings.
> > 
> > OK. But even if it is thread-safe, you also need to make sure it inits
> > the same. [...]
> 
> Interesting issue.  One openssl initialization call is deep inside
> libcurl, another one in libimaevm's solib ctor.  Neither is
> parametrized such that we could influence them.  However, things are
> working(tm).

Thanks for checking.

Cheers,

Mark