All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fan Wu <wufan@linux.microsoft.com>
To: Eric Biggers <ebiggers@kernel.org>, Paul Moore <paul@paul-moore.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, mpatocka@redhat.com, eparis@redhat.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 v19 15/20] fsverity: expose verified fsverity built-in signatures to LSMs
Date: Wed, 29 May 2024 20:38:41 -0700	[thread overview]
Message-ID: <aed4ed7d-9464-458a-9cc4-5d89ee9d8bb6@linux.microsoft.com> (raw)
In-Reply-To: <20240530030605.GA29189@sol.localdomain>



On 5/29/2024 8:06 PM, Eric Biggers wrote:
> On Wed, May 29, 2024 at 09:46:57PM -0400, Paul Moore wrote:
>> On Fri, May 24, 2024 at 4:46 PM Fan Wu <wufan@linux.microsoft.com> wrote:
>>>
>>> This patch enhances fsverity's capabilities to support both integrity and
>>> authenticity protection by introducing the exposure of built-in
>>> signatures through a new LSM hook. This functionality allows LSMs,
>>> e.g. IPE, to enforce policies based on the authenticity and integrity of
>>> files, specifically focusing on built-in fsverity signatures. It enables
>>> a policy enforcement layer within LSMs for fsverity, offering granular
>>> control over the usage of authenticity claims. 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 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
>>> that contain a verified built-in fsverity signature. This hook is invoked
>>> subsequent to the fsverity_verify_signature() process, guaranteeing the
>>> signature's verification against fsverity's keyring. This mechanism is
>>> crucial for maintaining system security, as it operates in kernel space,
>>> effectively thwarting attempts by malicious binaries to bypass user space
>>> stack interactions.
>>>
>>> The second to last commit in this patch set will add a link to the IPE
>>> documentation in fsverity.rst.
>>>
>>> Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
>>> Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
>>>
>>> ---
>>> v1-v6:
>>>    + Not present
>>>
>>> v7:
>>>    Introduced
>>>
>>> v8:
>>>    + Split fs/verity/ changes and security/ changes into separate patches
>>>    + Change signature of fsverity_create_info to accept non-const inode
>>>    + Change signature of fsverity_verify_signature to accept non-const inode
>>>    + Don't cast-away const from inode.
>>>    + Digest functionality dropped in favor of:
>>>      ("fs-verity: define a function to return the integrity protected
>>>        file digest")
>>>    + Reworded commit description and title to match changes.
>>>    + Fix a bug wherein no LSM implements the particular fsverity @name
>>>      (or LSM is disabled), and returns -EOPNOTSUPP, causing errors.
>>>
>>> v9:
>>>    + No changes
>>>
>>> v10:
>>>    + Rename the signature blob key
>>>    + Cleanup redundant code
>>>    + Make the hook call depends on CONFIG_FS_VERITY_BUILTIN_SIGNATURES
>>>
>>> v11:
>>>    + No changes
>>>
>>> v12:
>>>    + Add constification to the hook call
>>>
>>> v13:
>>>    + No changes
>>>
>>> v14:
>>>    + Add doc/comment to built-in signature verification
>>>
>>> v15:
>>>    + Add more docs related to IPE
>>>    + Switch the hook call to security_inode_setintegrity()
>>>
>>> v16:
>>>    + Explicitly mention "fsverity builtin signatures" in the commit
>>>      message
>>>    + Amend documentation in fsverity.rst
>>>    + Fix format issue
>>>    + Change enum name
>>>
>>> v17:
>>>    + Fix various documentation issues
>>>    + Use new enum name LSM_INT_FSVERITY_BUILTINSIG_VALID
>>>
>>> v18:
>>>    + Fix typos
>>>    + Move the inode_setintegrity hook call into fsverity_verify_signature()
>>>
>>> v19:
>>>    + Cleanup code w.r.t inode_setintegrity hook refactoring
>>> ---
>>>   Documentation/filesystems/fsverity.rst | 23 +++++++++++++++++++++--
>>>   fs/verity/signature.c                  | 18 +++++++++++++++++-
>>>   include/linux/security.h               |  1 +
>>>   3 files changed, 39 insertions(+), 3 deletions(-)
>>
>> Eric, can you give this patch in particular a look to make sure you
>> are okay with everything?  I believe Fan has addressed all of your
>> previous comments and it would be nice to have your Ack/Review tag if
>> you are okay with the current revision.
> 
> Sorry, I've just gotten a bit tired of finding so many basic issues in this
> patchset even after years of revisions.
> 
> This patch in particular is finally looking better.  There are a couple issues
> that I still see.  (BTW, you're welcome to review it too to help find these
> things, given that you seem to have an interest in getting this landed...):
> 
>> +	err = security_inode_setintegrity(inode,
>> +					  LSM_INT_FSVERITY_BUILTINSIG_VALID,
>> +					  signature,
>> +					  le32_to_cpu(sig_size));
> 
> This is doing le32_to_cpu() on a variable of type size_t, which will do the
> wrong thing on big endian systems and will generate a 'sparse' warning.
> 
Sorry for the mistake. As sig_size is already converted in open.c, there 
is indeed no need to call this function again. I will remove this 
unnecessary conversion.

> Also, the commit message still incorrectly claims that this patch allows
> "restricting kernel module loading from specified fsverity files via fsverity
> digests".  As I said before (sigh...), this is not correct as that can be done
> without this patch.
> 
> - Eric

As for the commit message, my intention was to provide an example of a 
policy that with the patch IPE can enforce, not to claim that this 
specific restriction requires the patch. However, I will remove it as it 
seems to be causing confusion.
-Fan

  reply	other threads:[~2024-05-30  3:38 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-24 20:46 [PATCH v19 00/20] Integrity Policy Enforcement LSM (IPE) Fan Wu
2024-05-24 20:46 ` [PATCH v19 01/20] security: add ipe lsm Fan Wu
2024-05-24 20:46 ` [PATCH v19 02/20] ipe: add policy parser Fan Wu
2024-05-24 20:46 ` [PATCH v19 03/20] ipe: add evaluation loop Fan Wu
2024-05-24 20:46 ` [PATCH v19 04/20] ipe: add LSM hooks on execution and kernel read Fan Wu
2024-05-24 20:46 ` [PATCH v19 05/20] initramfs|security: Add a security hook to do_populate_rootfs() Fan Wu
2024-05-24 20:46 ` [PATCH v19 06/20] ipe: introduce 'boot_verified' as a trust provider Fan Wu
2024-05-24 20:46 ` [PATCH v19 07/20] security: add new securityfs delete function Fan Wu
2024-05-24 20:46 ` [PATCH v19 08/20] ipe: add userspace interface Fan Wu
2024-05-24 20:46 ` [PATCH v19 09/20] uapi|audit|ipe: add ipe auditing support Fan Wu
2024-05-24 20:46 ` [PATCH v19 10/20] ipe: add permissive toggle Fan Wu
2024-05-24 20:46 ` [PATCH v19 11/20] block,lsm: add LSM blob and new LSM hooks for block device Fan Wu
2024-05-31 20:48   ` Eric Biggers
2024-05-24 20:46 ` [PATCH v19 12/20] dm verity: expose root hash digest and signature data to LSMs Fan Wu
2024-05-25  9:02   ` Mikulas Patocka
2024-05-31 21:07   ` Eric Biggers
2024-05-24 20:46 ` [PATCH v19 13/20] ipe: add support for dm-verity as a trust provider Fan Wu
2024-05-30  1:44   ` Paul Moore
2024-05-30  3:58     ` Fan Wu
2024-05-30  5:53       ` Jarkko Sakkinen
2024-05-30  5:49     ` Jarkko Sakkinen
2024-05-24 20:46 ` [PATCH v19 14/20] security: add security_inode_setintegrity() hook Fan Wu
2024-05-24 20:46 ` [PATCH v19 15/20] fsverity: expose verified fsverity built-in signatures to LSMs Fan Wu
2024-05-30  1:44   ` Paul Moore
2024-05-30  5:51     ` Jarkko Sakkinen
2024-05-30  6:01       ` Eric Biggers
2024-05-30  6:07         ` Jarkko Sakkinen
2024-05-30  1:46   ` Paul Moore
2024-05-30  3:06     ` Eric Biggers
2024-05-30  3:38       ` Fan Wu [this message]
2024-05-30 20:54       ` Paul Moore
2024-05-31  0:43         ` Eric Biggers
2024-05-31 15:51           ` Paul Moore
2024-05-31 17:47             ` Eric Biggers
2024-06-03  1:40               ` Paul Moore
2024-05-24 20:46 ` [PATCH v19 16/20] ipe: enable support for fs-verity as a trust provider Fan Wu
2024-05-24 20:46 ` [PATCH v19 17/20] scripts: add boot policy generation program Fan Wu
2024-05-24 20:46 ` [PATCH v19 18/20] ipe: kunit test for parser Fan Wu
2024-05-24 20:46 ` [PATCH v19 19/20] Documentation: add ipe documentation Fan Wu
2024-05-24 20:46 ` [PATCH v19 20/20] 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=aed4ed7d-9464-458a-9cc4-5d89ee9d8bb6@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=mpatocka@redhat.com \
    --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 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.