Re: [RFC][PATCH v3a 00/11] ima: support fs-verity digests and signatures (alternative)

[Eric Biggers]

On Thu, Jan 27, 2022 at 11:35:12AM -0800, Eric Biggers wrote:
> On Thu, Jan 27, 2022 at 07:46:09PM +0100, Roberto Sassu wrote:
> > I wanted to propose a different approach for handling fsverity digests and
> > signatures, compared to:
> > 
> > https://lore.kernel.org/linux-integrity/20220126000658.138345-1-zohar@xxxxxxxxxxxxx/
> > 
> > In the original proposal, a new signature version has been introduced (v3)
> > to allow the possibility of signing the digest of a more flexible data
> > structure, ima_file_id, which could also include the fsverity file digest.
> > 
> > While the new signature type would be sufficient to handle fsverity file
> > digests, the problem is that its format would not be compatible with the
> > signature format supported by the built-in verification module in fsverity.
> > The rpm package manager already has an extension to include fsverity
> > signatures, with the existing format, in the RPM header.
> > 
> > Given that the fsverity signature is in the PKCS#7 format, IMA has already
> > the capability of handling it with the existing code, more specifically the
> > modsig code. It would be sufficient to provide to modsig the correct data
> > to avoid introducing a new signature format.
> 
> I think it would be best to get people moved off of the fs-verity built-in
> signatures, rather than further extend the use of it.  PKCS#7 is a pretty
> terrible signature format.  The IMA one is better, though it's unfortunate that
> IMA still relies on X.509 for keys.

Note, the only reason that support for fs-verity built-in signatures was added
to RPM is that people didn't want to use IMA:
https://lore.kernel.org/linux-fscrypt/b49b4367-51e7-f62a-6209-b46a6880824b@xxxxxxxxx

If people are going to use IMA anyway, then there would be no point.

- Eric