Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <9bda9c8a9f161763f420bf8e7bd639fe0d7e1691.camel@linux.ibm.com>
Subject: Re: [PATCH v6 4/5] ima: support fs-verity file digest based version
 3 signatures
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Stefan Berger <stefanb@linux.ibm.com>,
        linux-integrity@vger.kernel.org
Cc:     Eric Biggers <ebiggers@kernel.org>, linux-fscrypt@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Fri, 25 Mar 2022 08:31:08 -0400
In-Reply-To: <d79baf40-6bb7-d4f4-666d-91e1ad20be74@linux.ibm.com>
References: <20220318182151.100847-1-zohar@linux.ibm.com>
         <20220318182151.100847-5-zohar@linux.ibm.com>
         <d79baf40-6bb7-d4f4-666d-91e1ad20be74@linux.ibm.com>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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