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
