From: Eric Biggers <ebiggers@kernel.org>
To: Fan Wu <wufan@linux.microsoft.com>
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: [PATCH v17 16/21] fsverity: expose verified fsverity built-in signatures to LSMs
Date: Wed, 24 Apr 2024 20:36:23 -0700 [thread overview]
Message-ID: <20240425033623.GA1401@sol.localdomain> (raw)
In-Reply-To: <1712969764-31039-17-git-send-email-wufan@linux.microsoft.com>
On Fri, Apr 12, 2024 at 05:55:59PM -0700, Fan Wu wrote:
> For instance, a policy could be established to permit the execution of all
> files with verified built-in fsverity signatures while restricting kernel
> module loading from specified fsverity files via fsverity digets.
"digets" => "digests"
> The introduction of a security_inode_setintegrity() hook call within
> fsverity's workflow ensures that the verified built-in signature of a file
> is exposed to LSMs, This enables LSMs to recognize and label fsverity files
"LSMs, This" => "LSMs. This"
> +#ifdef CONFIG_FS_VERITY_BUILTIN_SIGNATURES
> +static int fsverity_inode_setintegrity(struct inode *inode,
> + const struct fsverity_descriptor *desc)
> +{
> + return security_inode_setintegrity(inode,
> + LSM_INT_FSVERITY_BUILTINSIG_VALID,
> + desc->signature,
> + le32_to_cpu(desc->sig_size));
> +}
> +#else
> +static inline int fsverity_inode_setintegrity(struct inode *inode,
> + const struct fsverity_descriptor *desc)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_FS_VERITY_BUILTIN_SIGNATURES */
[...]
> @@ -241,6 +259,10 @@ struct fsverity_info *fsverity_create_info(const struct inode *inode,
> }
> }
>
> + err = fsverity_inode_setintegrity(inode, desc);
> + if (err)
> + goto fail;
> +
Wouldn't it be much simpler to put the LSM call in fsverity_verify_signature()?
Then no #ifdef would be needed, and there would be no weird cases where the LSM
gets passed LSM_INT_FSVERITY_BUILTINSIG_VALID with an empty signature.
> diff --git a/fs/verity/signature.c b/fs/verity/signature.c
> index 90c07573dd77..fd60e9704e78 100644
> --- a/fs/verity/signature.c
> +++ b/fs/verity/signature.c
> @@ -41,7 +41,11 @@ static struct key *fsverity_keyring;
> * @sig_size: size of signature in bytes, or 0 if no signature
> *
> * If the file includes a signature of its fs-verity file digest, verify it
> - * against the certificates in the fs-verity keyring.
> + * against the certificates in the fs-verity keyring. Note that signatures
> + * are verified regardless of the state of the 'fsverity_require_signatures'
> + * variable and the LSM subsystem relies on this behavior to help enforce
> + * file integrity policies. Please discuss changes with the LSM list
> + * (thank you!).
> *
> * Return: 0 on success (signature valid or not required); -errno on failure
> */
... and it would also make the above easier to understand if the LSM call were
to happen right in fsverity_verify_signature().
- Eric
next prev parent reply other threads:[~2024-04-25 3:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-13 0:55 [PATCH v17 00/21] Integrity Policy Enforcement LSM (IPE) Fan Wu
2024-04-13 0:55 ` [PATCH v17 01/21] security: add ipe lsm Fan Wu
2024-04-13 0:55 ` [PATCH v17 02/21] ipe: add policy parser Fan Wu
2024-04-13 0:55 ` [PATCH v17 03/21] ipe: add evaluation loop Fan Wu
2024-04-13 0:55 ` [PATCH v17 04/21] ipe: add LSM hooks on execution and kernel read Fan Wu
2024-04-13 0:55 ` [PATCH v17 05/21] initramfs|security: Add a security hook to do_populate_rootfs() Fan Wu
2024-04-13 0:55 ` [PATCH v17 06/21] ipe: introduce 'boot_verified' as a trust provider Fan Wu
2024-04-13 0:55 ` [PATCH v17 07/21] security: add new securityfs delete function Fan Wu
2024-04-13 0:55 ` [PATCH v17 08/21] ipe: add userspace interface Fan Wu
2024-04-13 0:55 ` [PATCH v17 09/21] uapi|audit|ipe: add ipe auditing support Fan Wu
2024-04-13 0:55 ` [PATCH v17 10/21] ipe: add permissive toggle Fan Wu
2024-04-13 0:55 ` [PATCH v17 11/21] block,lsm: add LSM blob and new LSM hooks for block device Fan Wu
2024-04-13 0:55 ` [PATCH v17 12/21] dm: add finalize hook to target_type Fan Wu
2024-04-13 0:55 ` [PATCH v17 13/21] dm verity: consume root hash digest and expose signature data via LSM hook Fan Wu
2024-04-25 3:56 ` Eric Biggers
2024-04-25 20:23 ` Fan Wu
2024-04-13 0:55 ` [PATCH v17 14/21] ipe: add support for dm-verity as a trust provider Fan Wu
2024-04-13 0:55 ` [PATCH v17 15/21] security: add security_inode_setintegrity() hook Fan Wu
2024-04-13 0:55 ` [PATCH v17 16/21] fsverity: expose verified fsverity built-in signatures to LSMs Fan Wu
2024-04-25 3:36 ` Eric Biggers [this message]
2024-04-13 0:56 ` [PATCH v17 17/21] ipe: enable support for fs-verity as a trust provider Fan Wu
2024-04-25 3:42 ` Eric Biggers
2024-04-25 4:20 ` Eric Biggers
2024-04-13 0:56 ` [PATCH v17 18/21] scripts: add boot policy generation program Fan Wu
2024-04-13 0:56 ` [PATCH v17 19/21] ipe: kunit test for parser Fan Wu
2024-04-13 0:56 ` [PATCH v17 20/21] Documentation: add ipe documentation Fan Wu
2024-04-15 12:11 ` Bagas Sanjaya
2024-04-15 14:56 ` Randy Dunlap
2024-04-17 10:05 ` Bagas Sanjaya
2024-04-25 4:13 ` Eric Biggers
2024-04-25 4:36 ` Eric Biggers
2024-04-13 0:56 ` [PATCH v17 21/21] MAINTAINERS: ipe: add ipe maintainer information 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=20240425033623.GA1401@sol.localdomain \
--to=ebiggers@kernel.org \
--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=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=serge@hallyn.com \
--cc=snitzer@kernel.org \
--cc=tytso@mit.edu \
--cc=wufan@linux.microsoft.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.