Re: [PATCH 0/7] Split fsverity-utils into a shared library

[Jes Sorensen <jes.sorensen@gmail.com>]

On 2/11/20 2:22 PM, Eric Biggers wrote:
> Hi Jes,
> 
> On Mon, Feb 10, 2020 at 07:00:30PM -0500, Jes Sorensen wrote:
>> From: Jes Sorensen <jsorensen@fb.com>
>> If we can agree on the approach, then I am happy to deal with the full
>> libtoolification etc.
> 
> Before we do all this work, can you take a step back and explain the use case so
> that we can be sure it's really worthwhile?
> 
> fsverity_cmd_enable() and fsverity_cmd_measure() would just be trivial wrappers
> around the FS_IOC_ENABLE_VERITY and FS_IOC_MEASURE_VERITY ioctls, so they don't
> need a library.  [Aside: I'd suggest calling these fsverity_enable() and
> fsverity_measure(), and leaving "cmd" for the command-line wrappers.] 
> 
> That leaves signing as the only real point of the library.  But do you actually
> need to be able to *sign* the files via the rpm binary, or do you just need to
> be able to install already-created signatures?  I.e., can the signatures instead
> just be created with 'fsverity sign' when building the RPMs?

So I basically want to be able to carry verity signatures in RPM as RPM
internal data, similar to how it supports IMA signatures. I want to be
able to install those without relying on post-install scripts and
signature files being distributed as actual files that gets installed,
just to have to remove them. This is how IMA support is integrated into
RPM as well.

Right now the RPM approach for signatures involves two steps, a build
digest phase, and a sign the digest phase.

The reason I included enable and measure was for completeness. I don't
care wildly about those.

> Separately, before you start building something around fs-verity's builtin
> signature verification support, have you also considered adding support for
> fs-verity to IMA?  I.e., using the fs-verity hashing mechanism with the IMA
> signature mechanism.  The IMA maintainer has been expressed interested in that.
> If rpm already supports IMA signatures, maybe that way would be a better fit?

I looked at IMA and it is overly complex. It is not obvious to me how
you would get around that without the full complexity of IMA? The beauty
of fsverity's approach is the simplicity of relying on just the kernel
keyring for validation of the signature. If you have explicit
suggestions, I am certainly happy to look at it.

Thanks,
Jes