On Thu, Feb 26, 2026 at 12:22:32PM -0500, Stefan Berger wrote: > > I see that IMA indeed never upgraded full file hashes to use > > 'struct ima_file_id'. Building a new feature that relies on this seems > > like a bad idea though, given that it's a security bug that makes the> IMA > protocol cryptographically ambiguous. I.e., it means that in IMA, > > when the contents of some file are signed, that signature is sometimes > > also valid for some other file contents which the signer didn't intend. > > You mean IMA should not sign the digest in the ima_file_id structure but > hash the ima_file_id structure in which this file digest is written into > (that we currently sign) and sign/verify this digest? And we would do this > to avoid two different files (with presumably different content) from having > the same hashes leading to the same signature? Which hashes (besides the > non-recommended ones) are so weak now that you must not merely sign a file's > hash? > > The problem with this is that older kernels (without patching) won't be able > to handle newer signatures.
IMA needs to sign the entire ima_file_id structure, which is indeed what IMA already does when it uses that structure. (Well, actually it signs a hash of the struct, but that's best thought of an implementation detail of legacy signature algorithms that can only sign hashes. For a modern algorithm the whole struct should be passed instead.) Just IMA uses that structure only for fsverity hashes, which is a bug that makes the IMA protocol ambiguous. It needs to use ima_file_id consistently, otherwise a signed message sometimes corresponds to multiple unique file contents even without a break in the cryptographic hash function. Sure, when that bug is fixed, old kernels won't support the new signatures for files that use a full-file hash. But the same applies to starting to use a new signature algorithm, such as ML-DSA. - Eric
