linux-kernel - Re: [RFC PATCH v13 17/20] ipe: enable support for fs-verity as a trust provider

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: <b73e3387-558f-4f40-8741-c6ed7965b25f@linux.microsoft.com>
Date: Thu, 29 Feb 2024 10:59:21 -0800
From: Fan Wu <wufan@...ux.microsoft.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: corbet@....net, zohar@...ux.ibm.com, jmorris@...ei.org, serge@...lyn.com,
 tytso@....edu, axboe@...nel.dk, agk@...hat.com, snitzer@...nel.org,
 eparis@...hat.com, paul@...l-moore.com, linux-doc@...r.kernel.org,
 linux-integrity@...r.kernel.org, linux-security-module@...r.kernel.org,
 linux-fscrypt@...r.kernel.org, linux-block@...r.kernel.org,
 dm-devel@...ts.linux.dev, audit@...r.kernel.org,
 linux-kernel@...r.kernel.org, Deven Bowers <deven.desai@...ux.microsoft.com>
Subject: Re: [RFC PATCH v13 17/20] ipe: enable support for fs-verity as a
 trust provider



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