Re: [PATCH] PR28204, debuginfod IMA

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

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

I interpret this as a veto for the "optimistic" mode.  Too bad, this
is going to reduce usability and utility.  What mode do you want by
default then, "ignore" or "enforcing"?


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

They use unpublished private keys to sign files.  Public certificates
allow anyone to verify the signatures.


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

I assume you mean to require users to manually download & install them
somehow.


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

Certificates are public keys.  They are literally designed for wide
distribution.  They may be authenticated further by certificate
chains, but there is little harm to even crafted certificates.  They
would not be usable to verify signatures, leaving the user no worse
off than without the certs.


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

I interpret that as a veto.


> > 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 :{

I interpret that as a veto.  OK, will have to set time aside to
rewrite this code.


- FChE