linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Fan Wu <wufan@linux.microsoft.com>
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>
Subject: Re: [RFC PATCH v13 17/20] ipe: enable support for fs-verity as a trust provider
Date: Thu, 29 Feb 2024 10:59:21 -0800	[thread overview]
Message-ID: <b73e3387-558f-4f40-8741-c6ed7965b25f@linux.microsoft.com> (raw)
In-Reply-To: <20240229044625.GA1946@sol.localdomain>



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

  reply	other threads:[~2024-02-29 18:59 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-29  0:54 [RFC PATCH v13 00/20] Integrity Policy Enforcement LSM (IPE) Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 01/20] security: add ipe lsm Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 02/20] ipe: add policy parser Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 03/20] ipe: add evaluation loop Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 04/20] ipe: add LSM hooks on execution and kernel read Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 05/20] initramfs|security: Add a security hook to do_populate_rootfs() Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 06/20] ipe: introduce 'boot_verified' as a trust provider Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 07/20] security: add new securityfs delete function Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 08/20] ipe: add userspace interface Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 09/20] uapi|audit|ipe: add ipe auditing support Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 10/20] ipe: add permissive toggle Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 11/20] block|security: add LSM blob to block_device Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 12/20] dm verity: set DM_TARGET_SINGLETON feature flag Fan Wu
2024-03-02 16:01   ` Mike Snitzer
2024-02-29  0:54 ` [RFC PATCH v13 13/20] dm: add finalize hook to target_type Fan Wu
2024-03-02 16:13   ` Mike Snitzer
2024-02-29  0:54 ` [RFC PATCH v13 14/20] dm verity: consume root hash digest and signature data via LSM hook Fan Wu
2024-03-02 16:22   ` Mike Snitzer
2024-03-02 16:37   ` Mike Snitzer
2024-02-29  0:54 ` [RFC PATCH v13 15/20] ipe: add support for dm-verity as a trust provider Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 16/20] fsverity: consume builtin signature via LSM hook Fan Wu
2024-02-29  0:54 ` [RFC PATCH v13 17/20] ipe: enable support for fs-verity as a trust provider Fan Wu
2024-02-29  4:01   ` Randy Dunlap
2024-02-29  4:46   ` Eric Biggers
2024-02-29 18:59     ` Fan Wu [this message]
2024-02-29 19:42       ` Eric Biggers
2024-02-29 19:59         ` Fan Wu
2024-02-29  0:55 ` [RFC PATCH v13 18/20] scripts: add boot policy generation program Fan Wu
2024-02-29  0:55 ` [RFC PATCH v13 19/20] ipe: kunit test for parser Fan Wu
2024-02-29  0:55 ` [RFC PATCH v13 20/20] documentation: add ipe documentation Fan Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b73e3387-558f-4f40-8741-c6ed7965b25f@linux.microsoft.com \
    --to=wufan@linux.microsoft.com \
    --cc=agk@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=deven.desai@linux.microsoft.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=ebiggers@kernel.org \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=snitzer@kernel.org \
    --cc=tytso@mit.edu \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).