Received-SPF: pass (google.com: domain of linux-kernel+bounces-87324-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <b73e3387-558f-4f40-8741-c6ed7965b25f@linux.microsoft.com>
Date: Thu, 29 Feb 2024 10:59:21 -0800
Precedence: bulk
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 <ebiggers@kernel.org>
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 <deven.desai@linux.microsoft.com>
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 <wufan@linux.microsoft.com>
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