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
