From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 86AE17828A; Thu, 29 Feb 2024 18:59:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709233169; cv=none; b=V9rAWC0Wivb9LbEyJMQrTyZUIsYXrtNQn5NENtoEViRgxOLyHjquLNc1gVbNf8Et6lOuDmhIFOVpHxqWxV5k4LWDN22o3ZSyQeRQVrRoFmHNXKqhw4/b9yCV/2ofbndmkfS49/8/l8Sa34LMSz0EkhPSOLdLoA9P57PZs9Bdvcs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709233169; c=relaxed/simple; bh=03wrvTX4PmazfhRynJz8dIwWNCpXUtctCoHli5CWq3k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BSiHEnK1bdl+ZO+qo/qnoUUG9LdFoS69mI789yi1f9M4hbQlP3TwSgZ4QgZw1CoRcTC1YdEaJ0nHdnKXs7DNBqKU9nmfQH3VkmTrcvK8pDbKiasf/pkmrHecWZoQDAUZ0B6jEZODhMuABiCXqLDyvfZGtqsbP5IevGcsG/q6MCI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=Chwd/gWh; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="Chwd/gWh" Received: from [10.137.106.151] (unknown [131.107.8.87]) by linux.microsoft.com (Postfix) with ESMTPSA id 67BEC20B74C1; Thu, 29 Feb 2024 10:59:21 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 67BEC20B74C1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1709233161; bh=JV+3tSiFvjDV+NVnRDenCsHCjaCafQUqnYHRslOz/Is=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Chwd/gWhaBwu6cGDHeTQLShmFSuRlHjpipSjMmiY+uPVfP9m8FVNjLOHiAxx+ZPF/ mebhxmfmUfYNWYgKAjhshktx0kymWEOFVKFUkQGBgOaJ0lidTIXk/2OEIuZ/FtL46I mzpviYdU/EUUFj7yvd/zQgv5h89QqsFhP/icO91I= Message-ID: Date: Thu, 29 Feb 2024 10:59:21 -0800 Precedence: bulk X-Mailing-List: audit@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v13 17/20] ipe: enable support for fs-verity as a trust provider To: Eric Biggers Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com, tytso@mit.edu, axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org, eparis@redhat.com, paul@paul-moore.com, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@lists.linux.dev, audit@vger.kernel.org, linux-kernel@vger.kernel.org, Deven Bowers References: <1709168102-7677-1-git-send-email-wufan@linux.microsoft.com> <1709168102-7677-18-git-send-email-wufan@linux.microsoft.com> <20240229044625.GA1946@sol.localdomain> Content-Language: en-CA From: Fan Wu In-Reply-To: <20240229044625.GA1946@sol.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/28/2024 8:46 PM, Eric Biggers wrote: > On Wed, Feb 28, 2024 at 04:54:59PM -0800, Fan Wu wrote: >> diff --git a/security/ipe/hooks.c b/security/ipe/hooks.c >> index f5190a1347a6..ca1573ff21b7 100644 >> --- a/security/ipe/hooks.c >> +++ b/security/ipe/hooks.c >> @@ -254,3 +254,33 @@ int ipe_bdev_setsecurity(struct block_device *bdev, const char *key, >> return -EOPNOTSUPP; >> } >> #endif /* CONFIG_IPE_PROP_DM_VERITY */ >> + >> +#ifdef CONFIG_IPE_PROP_FS_VERITY >> +/** >> + * ipe_inode_setsecurity - Sets fields of a inode security blob from @key. >> + * @inode: The inode to source the security blob from. >> + * @name: The name representing the information to be stored. >> + * @value: The value to be stored. >> + * @size: The size of @value. >> + * @flags: unused >> + * >> + * Saves fsverity signature & digest into inode security blob >> + * >> + * Return: >> + * * 0 - OK >> + * * !0 - Error >> + */ >> +int ipe_inode_setsecurity(struct inode *inode, const char *name, >> + const void *value, size_t size, >> + int flags) >> +{ >> + struct ipe_inode *inode_sec = ipe_inode(inode); >> + >> + if (!strcmp(name, FS_VERITY_INODE_SEC_NAME)) { >> + inode_sec->fs_verity_signed = size > 0 && value; >> + return 0; >> + } >> + >> + return -EOPNOTSUPP; >> +} > > So IPE is interested in whether a file has an fsverity builtin signature, but it > doesn't care what the signature is or whether it has been checked. What is the > point? > > - Eric It does make sure the signature is checked. This hook call can only be triggered after fsverity_verify_signature() succeed. Therefore, for files that are marked with the security blob inode_sec->fs_verity_sign as true, they must successfully pass the fsverity_verify_signature() check. Regarding the other question, the current version does not support defining policies to trust files based on the inner content of their signatures because the current patch set is already too large. We plan to introduce new policy grammars to enable the policy to define which certificate of the signature can be trusted after this version is accepted. -Fan