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>, 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 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).