public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Fan Wu <wufan@linux.microsoft.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>,
	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, fsverity@lists.linux.dev,
	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 v15 18/21] ipe: enable support for fs-verity as a trust provider
Date: Mon, 18 Mar 2024 13:58:23 -0700	[thread overview]
Message-ID: <02453956-46d0-40f4-9e20-1bb0808996bb@linux.microsoft.com> (raw)
In-Reply-To: <53a067f80db2e53ae29dc811515ab51c6ef86aed.camel@huaweicloud.com>



On 3/18/2024 1:08 AM, Roberto Sassu wrote:
> On Sun, 2024-03-17 at 22:17 -0700, Eric Biggers wrote:
>> On Fri, Mar 15, 2024 at 08:35:48PM -0700, Fan Wu wrote:
>>> +config IPE_PROP_FS_VERITY
>>> +	bool "Enable property for fs-verity files"
>>> +	depends on FS_VERITY && FS_VERITY_BUILTIN_SIGNATURES
>>> +	help
>>> +	  This option enables the usage of properties "fsverity_signature"
>>> +	  and "fsverity_digest". These properties evaluate to TRUE when
>>> +	  a file is fsverity enabled and with a signed digest
>>
>> Again: why would anyone care if there is a signature, if that signature is not
>> checked.
>>
>> I think you meant to write something like: "when a file is fsverity enabled and
>> has a valid builtin signature whose signing cert is in the .fs-verity keyring".
> 
> I was also thinking the same. I didn't follow the recent development
> closely, but unless IPE locks somehow the .fs-verity keyring, the
> property you suggested would not be immutable. Meaning that someone can
> add/remove a key in that keyring, making the property true or false.
> 
> Roberto

Yes, the .fs-verity keyring's mutability could affect the property's 
immutability. However, we are not planing to "lock" the keyrings, but we 
would like to use policies languages to express what certificate can be 
trusted.

For example, we can have a rule like this:

#Certificate declaration
CERTIFICATE=MyCertificate CertThumbprint=DummyThumbprint
op=EXECUTE fsverity_signature=MyCertificate action=ALLOW

This will be our immediate next work after the initial version is accepted.

-Fan


  reply	other threads:[~2024-03-18 20:58 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-16  3:35 [RFC PATCH v15 00/21] Integrity Policy Enforcement LSM (IPE) Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 01/21] security: add ipe lsm Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 02/21] ipe: add policy parser Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 03/21] ipe: add evaluation loop Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 04/21] ipe: add LSM hooks on execution and kernel read Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 05/21] initramfs|security: Add a security hook to do_populate_rootfs() Fan Wu
2024-03-18  0:29   ` Casey Schaufler
2024-03-18  1:58     ` Paul Moore
2024-03-16  3:35 ` [RFC PATCH v15 06/21] ipe: introduce 'boot_verified' as a trust provider Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 07/21] security: add new securityfs delete function Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 08/21] ipe: add userspace interface Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 09/21] uapi|audit|ipe: add ipe auditing support Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 10/21] ipe: add permissive toggle Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 11/21] block|security: add LSM blob to block_device Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 12/21] security: add security_bdev_setintegrity() hook Fan Wu
2024-03-19 23:00   ` [PATCH RFC " Paul Moore
2024-03-20  8:28     ` Jarkko Sakkinen
2024-03-20  8:31       ` Jarkko Sakkinen
2024-03-20 20:31         ` Fan Wu
2024-03-21 17:25           ` Jarkko Sakkinen
2024-03-16  3:35 ` [RFC PATCH v15 13/21] dm: add finalize hook to target_type Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 14/21] dm verity: consume root hash digest and signature data via LSM hook Fan Wu
2024-03-19 23:00   ` [PATCH RFC " Paul Moore
2024-03-20  2:19     ` Mike Snitzer
2024-03-20 17:23       ` Paul Moore
2024-03-20 18:49         ` Mike Snitzer
2024-03-20 17:56     ` Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 15/21] ipe: add support for dm-verity as a trust provider Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 16/21] security: add security_inode_setintegrity() hook Fan Wu
2024-03-19 23:00   ` [PATCH RFC " Paul Moore
2024-03-16  3:35 ` [RFC PATCH v15 17/21] fsverity: consume builtin signature via LSM hook Fan Wu
2024-03-18  5:29   ` Eric Biggers
2024-03-19 23:00     ` Paul Moore
2024-03-16  3:35 ` [RFC PATCH v15 18/21] ipe: enable support for fs-verity as a trust provider Fan Wu
2024-03-18  5:17   ` Eric Biggers
2024-03-18  8:08     ` Roberto Sassu
2024-03-18 20:58       ` Fan Wu [this message]
2024-03-18 20:40     ` Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 19/21] scripts: add boot policy generation program Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 20/21] ipe: kunit test for parser Fan Wu
2024-03-16  3:35 ` [RFC PATCH v15 21/21] 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=02453956-46d0-40f4-9e20-1bb0808996bb@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=fsverity@lists.linux.dev \
    --cc=jmorris@namei.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@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=roberto.sassu@huaweicloud.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