Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3676399rwb; Fri, 16 Dec 2022 20:01:58 -0800 (PST) X-Google-Smtp-Source: AMrXdXtGHzzOn5DEm2aNK672HDZ17yQlZle7aCB5XpOG3vkdA+GzonKEB4AQePKXaNvgKzJY/am/ X-Received: by 2002:a05:6a20:1bd5:b0:a9:fddb:9eab with SMTP id cv21-20020a056a201bd500b000a9fddb9eabmr910408pzb.41.1671249718758; Fri, 16 Dec 2022 20:01:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671249718; cv=none; d=google.com; s=arc-20160816; b=uU9vAFBcf51I6O53iTuktGF/f46oCTY+quis3ZJe37oO1vSRTksR5/kE5o2s28vXfY P51vFEPhkSQmERFNwnCGRh5P1dD6LX70nfdURZzzweuq9yQnjKAqPB6LCOjaDikTRT1c D0fy7Kmvpuo46CgMX8Etye2ZR1yITQdJTXXyOd/FFFoLUUxnUmDs/C4eOLY+poN0Vf8j RDeobtinpemnmPac/pOjY/zMzqKKQc7XI+gVycfYb0leEIESbJI9c6SH/sGcE1tKFXrt Ltx/cBMJT+UWEaAEfBjhugVM6fIiKQ8g9c4rtEiDiY423Pc1mTrBcC1VEZo31guy0IPW ZUyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=4aQSOprobNbd+6jrn5QD+kNnzjk79RkuNsA0skg8Tj8=; b=M1/mkUADYSoymqSZvhGIDgpMDXpIzDKA+4hAnjyQaennGshC8OZ1vIDq+ENFYzt+rv W9i2M50qiAK52TWnwIqwZcdpeWKkkWpJnqxFpub8UCFbyVOWgC4DGC/+t/QHIQot3o0i Rb8JxtL9ShrwtOvh7/9ySJP4SgOR0FgHzArRohroqWB/TlsJ2m5lDM8+/YcvDoiCAep1 pCSOM7Z1Qd10iBV8mYYUU4Olb1IDv8BTUyevSfeb2OeplUo/9RrL9LJvDAiMXpeFdtcg gwMjx65hD39x9wGFgSXB6PNqq1v/3gDtcjghNL1aAQxsxKQsMzWASKnjDD8Q70etg9Ay Lbeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OQ2qyig1; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id li4-20020a17090b48c400b0020ab20c54fesi9649587pjb.114.2022.12.16.20.01.37; Fri, 16 Dec 2022 20:01:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OQ2qyig1; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229480AbiLQDxO (ORCPT + 99 others); Fri, 16 Dec 2022 22:53:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229948AbiLQDxM (ORCPT ); Fri, 16 Dec 2022 22:53:12 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E40C6C723; Fri, 16 Dec 2022 19:53:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B60D56231A; Sat, 17 Dec 2022 03:53:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE2F8C433EF; Sat, 17 Dec 2022 03:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671249190; bh=tvtSBxOjRjr8AD1Nit2OYvq2xfn8/939ipq48vK7DLA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OQ2qyig1Ro+5frbEspzt9RXufwAwYshGg5d/dnepFr7yiNB6dz+tgePcHbW3H1RT7 8d6i52uzaJJyvYaWAVgr19fW4UdciX/9S1s+C6SNHKoGAXFV0QFHu8bwtVAcClSo8p kOV6h2wVMqvmCis34nqkPTeRqwqxPC+GsoBhuGquiUVVdiDW6Z/m5tDHT/+79HUzsV pjzmUlxnremRXcnNzaH3wrqw2Hi2D++kss1HCA8m3PNijYr8JELSHf54b1fzz00O9s DZ8XBgSOtMmMoBQ+jkerirWRfZ1IxljS3goEfWl9Dz2gXH15Y5aTcWjR4a40EKqkwF mENXqYKlr8Vag== Date: Fri, 16 Dec 2022 19:53:07 -0800 From: Eric Biggers To: Luca Boccassi Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, linux-integrity@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] fsverity: don't check builtin signatures when require_signatures=0 Message-ID: References: <20221208033523.122642-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sat, Dec 17, 2022 at 02:06:04AM +0000, Luca Boccassi wrote: > On Fri, 16 Dec 2022 at 21:06, Eric Biggers wrote: > > > > On Thu, Dec 08, 2022 at 08:42:56PM +0000, Luca Boccassi wrote: > > > On Thu, 8 Dec 2022 at 03:35, Eric Biggers wrote: > > > > > > > > From: Eric Biggers > > > > > > > > An issue that arises when migrating from builtin signatures to userspace > > > > signatures is that existing files that have builtin signatures cannot be > > > > opened unless either CONFIG_FS_VERITY_BUILTIN_SIGNATURES is disabled or > > > > the signing certificate is left in the .fs-verity keyring. > > > > > > > > Since builtin signatures provide no security benefit when > > > > fs.verity.require_signatures=0 anyway, let's just skip the signature > > > > verification in this case. > > > > > > > > Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures") > > > > Cc: # v5.4+ > > > > Signed-off-by: Eric Biggers > > > > --- > > > > fs/verity/signature.c | 18 ++++++++++++++++-- > > > > 1 file changed, 16 insertions(+), 2 deletions(-) > > > > > > Acked-by: Luca Boccassi > > > > So if I can't apply > > https://lore.kernel.org/linux-fscrypt/20221208033548.122704-1-ebiggers@kernel.org > > ("fsverity: mark builtin signatures as deprecated") due to IPE, wouldn't I not > > be able to apply this patch either? Surely IPE isn't depending on > > fs.verity.require_signatures=1, given that it enforces the policy itself? > > I'm not sure what you mean? Skipping verification when this syscfg is > disabled makes sense to me, as you noted it doesn't serve any purpose > in that case. Currently, fsverity builtin signatures are only useful if fs.verity.require_signatures is set to 1 *and* userspace actually checks that files have fsverity enabled. However, IPE would change that if it actually gets merged upstream, at least based on the version that was most recently sent out. It would introduce a use of fsverity builtin signatures directly in the kernel (https://lore.kernel.org/r/1654714889-26728-14-git-send-email-deven.desai@linux.microsoft.com and https://lore.kernel.org/r/1654714889-26728-15-git-send-email-deven.desai@linux.microsoft.com). IIUC, the IPE patches add code that checks whether a file has a fsverity builtin signature, and if so it assumes that it was verified by fs/verity/ and creates a *boolean* file property "fsverity_signature" for IPE to operate on. Since the IPE patches check for the presence of a builtin signature directly, instead of indirectly by checking whether the inode has fsverity enabled at all, there would be no need for the fs.verity.require_signatures setting with IPE. The IPE patches do assume that the signature, if present, always gets verified by fs/verity/. That's what this patch would break. Of course, for upstream I shouldn't care about breaking out-of-tree code. So I could apply this anyway. But I'd at least like to be consistent. If "fsverity: mark builtin signatures as deprecated" isn't going to be applied because of IPE, then I'd think this patch shouldn't be applied either, for the same reason... - Eric