On Mon, 2022-03-21 at 09:10 -0400, Stefan Berger wrote: > > On 3/18/22 14:21, Mimi Zohar wrote: > > IMA may verify a file's integrity against a "good" value stored in the > > 'security.ima' xattr or as an appended signature, based on policy. When > > the "good value" is stored in the xattr, the xattr may contain a file > > hash or signature. In either case, the "good" value is preceded by a > > header. The first byte of the xattr header indicates the type of data > > - hash, signature - stored in the xattr. To support storing fs-verity > > signatures in the 'security.ima' xattr requires further differentiating > > the fs-verity signature from the existing IMA signature. > > > > In addition the signatures stored in 'security.ima' xattr, need to be > > disambiguated. Instead of directly signing the fs-verity digest, a new > > signature version 3 is defined as the hash of the ima_file_id structure, > > which identifies the type of signature and the digest. > > Would it not be enough to just differentiat by the type of signature > rather than also bumping the version? It's still signature_v2_hdr but a > new type IMA_VERITY_DIGSIG is introduced there that shoud be sufficient > to indicate that a different method for calculating the hash is to be > used than for anything that existed before? sigv3 would then become the > more obvious veriftysig... ? One of Eric's concerns was that, "an attacker (who controls the file's contents and IMA xattr) [could] replace the file with one with a differrent content and still be able to pass the IMA check." His solution was to only allow one signature version on a running system. For the complete description of the attack, refer to Eric's comments on v3. Instead of only allowing one signature version on a running system, subsequent versions of this patch set addressed his concern, by limiting the signature version based on policy. -- thanks, Mimi
