linux-kernel - Re: [PATCH v6 4/5] ima: support fs-verity file digest based version 3 signatures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d79baf40-6bb7-d4f4-666d-91e1ad20be74@linux.ibm.com>
Date:   Mon, 21 Mar 2022 09:10:22 -0400
From:   Stefan Berger <stefanb@...ux.ibm.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>, linux-integrity@...r.kernel.org
Cc:     Eric Biggers <ebiggers@...nel.org>, linux-fscrypt@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 4/5] ima: support fs-verity file digest based version 3
 signatures



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... ?