From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Paul Moore <paul@paul-moore.com>,
viro@zeniv.linux.org.uk, brauner@kernel.org,
chuck.lever@oracle.com, jlayton@kernel.org, neilb@suse.de,
kolga@netapp.com, Dai.Ngo@oracle.com, tom@talpey.com,
jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com,
dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com,
dhowells@redhat.com, jarkko@kernel.org,
stephen.smalley.work@gmail.com, eparis@parisplace.org,
casey@schaufler-ca.com, shuah@kernel.org, mic@digikod.net
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
selinux@vger.kernel.org, linux-kselftest@vger.kernel.org,
Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH v9 0/25] security: Move IMA and EVM to the LSM infrastructure
Date: Thu, 08 Feb 2024 09:05:54 +0100 [thread overview]
Message-ID: <dd8a979df500489c0d8595f9a3f89c801ce6f1c2.camel@huaweicloud.com> (raw)
In-Reply-To: <d54ca249c3071522218c7ba7b4984bab@paul-moore.com>
On Wed, 2024-02-07 at 22:18 -0500, Paul Moore wrote:
> On Jan 15, 2024 Roberto Sassu <roberto.sassu@huaweicloud.com> wrote:
> >
> > IMA and EVM are not effectively LSMs, especially due to the fact that in
> > the past they could not provide a security blob while there is another LSM
> > active.
> >
> > That changed in the recent years, the LSM stacking feature now makes it
> > possible to stack together multiple LSMs, and allows them to provide a
> > security blob for most kernel objects. While the LSM stacking feature has
> > some limitations being worked out, it is already suitable to make IMA and
> > EVM as LSMs.
> >
> > The main purpose of this patch set is to remove IMA and EVM function calls,
> > hardcoded in the LSM infrastructure and other places in the kernel, and to
> > register them as LSM hook implementations, so that those functions are
> > called by the LSM infrastructure like other regular LSMs.
>
> Thanks Roberto, this is looking good. I appreciate all the work you've
> put into making this happen; when I first mentioned this idea I figured
> it would be something that would happen much farther into the future, I
> wasn't expecting to see you pick this up and put in the work to make it
> happen - thank you.
Thanks! I also appreciate a lot your guidance and suggestions.
> I had some pretty minor comments but I think the only thing I saw that
> I think needs a change/addition is a comment in the Makefile regarding
> the IMA/EVM ordering; take a look and let me know what you think.
Oh, I remember well, it is there but difficult to spot...
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -18,5 +18,6 @@ integrity-$(CONFIG_LOAD_IPL_KEYS) += platform_certs/load_ipl_s390.o
integrity-$(CONFIG_LOAD_PPC_KEYS) += platform_certs/efi_parser.o \
platform_certs/load_powerpc.o \
platform_certs/keyring_handler.o
+# The relative order of the 'ima' and 'evm' LSMs depends on the order below.
obj-$(CONFIG_IMA) += ima/
obj-$(CONFIG_EVM) += evm/
> There are also a few patches in the patchset that don't have an
> ACK/review tag from Mimi, although now that you are co-maininting IMA/EVM
> with Mimi I don't know if that matters. If the two of you can let me
> know how you want me to handle LSM patches that are IMA/EVM related I
> would appreciate it (two ACKs, one or other, something else?).
Ok, we will come back to you about this.
> Once you add a Makefile commane and we sort out the IMA/EVM approval
> process I think we're good to get this into linux-next. A while back
> Mimi and I had a chat offline and if I recall everything correctly she
> preferred that I take this patchset via the LSM tree. I don't have a
> problem with that, and to be honest I would probably prefer
> that too, but I wanted to check with everyone that is still the case.
> Just in case, I've added my ACKs/reviews to this patchset in case this
> needs to be merged via the integrity tree.
Ok, given that there is the comment in the Makefile, the last thing to
do from your side is to remove the vague comment in the file_release
patch.
Other than that, I think Mimi wanted to give a last look. If that is
ok, then the patches should be ready for your repo and linux-next.
Thanks
Roberto
next prev parent reply other threads:[~2024-02-08 8:06 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 18:17 [PATCH v9 00/25] security: Move IMA and EVM to the LSM infrastructure Roberto Sassu
2024-01-15 18:17 ` [PATCH v9 01/25] ima: Align ima_inode_post_setattr() definition with " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 1/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 02/25] ima: Align ima_file_mprotect() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 2/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 03/25] ima: Align ima_inode_setxattr() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 3/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 04/25] ima: Align ima_inode_removexattr() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 4/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 05/25] ima: Align ima_post_read_file() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 5/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 06/25] evm: Align evm_inode_post_setattr() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 6/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 07/25] evm: Align evm_inode_setxattr() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 7/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 08/25] evm: Align evm_inode_post_setxattr() " Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 8/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 09/25] security: Align inode_setattr hook definition with EVM Roberto Sassu
2024-02-08 3:18 ` [PATCH v9 9/25] " Paul Moore
2024-01-15 18:17 ` [PATCH v9 10/25] security: Introduce inode_post_setattr hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 10:17 ` Christian Brauner
2024-01-15 18:17 ` [PATCH v9 11/25] security: Introduce inode_post_removexattr hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 10:17 ` Christian Brauner
2024-01-15 18:17 ` [PATCH v9 12/25] security: Introduce file_post_open hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:56 ` Christian Brauner
2024-02-09 9:59 ` Christian Brauner
2024-02-09 10:12 ` Christian Brauner
2024-02-09 10:46 ` Roberto Sassu
2024-02-09 11:34 ` Christian Brauner
2024-02-09 12:02 ` Roberto Sassu
2024-02-12 21:00 ` Mimi Zohar
2024-02-12 21:16 ` Paul Moore
2024-02-13 12:58 ` Roberto Sassu
2024-02-13 15:33 ` Paul Moore
2024-02-14 20:07 ` Mimi Zohar
2024-02-14 21:21 ` Paul Moore
2024-02-15 8:16 ` Mimi Zohar
2024-02-15 15:02 ` Paul Moore
2024-01-15 18:17 ` [PATCH v9 13/25] security: Introduce file_release hook Roberto Sassu
2024-01-15 19:15 ` Al Viro
2024-01-16 8:47 ` Roberto Sassu
2024-01-16 16:51 ` Casey Schaufler
2024-01-16 17:33 ` Al Viro
2024-01-16 18:18 ` Casey Schaufler
2024-02-08 3:18 ` Paul Moore
2024-02-09 10:15 ` Christian Brauner
2024-02-12 17:21 ` Stefan Berger
2024-01-15 18:17 ` [PATCH v9 14/25] security: Introduce path_post_mknod hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:54 ` Christian Brauner
2024-02-12 17:23 ` Stefan Berger
2024-01-15 18:17 ` [PATCH v9 15/25] security: Introduce inode_post_create_tmpfile hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:53 ` Christian Brauner
2024-02-12 17:26 ` Stefan Berger
2024-01-15 18:18 ` [PATCH v9 16/25] security: Introduce inode_post_set_acl hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:51 ` Christian Brauner
2024-01-15 18:18 ` [PATCH v9 17/25] security: Introduce inode_post_remove_acl hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:52 ` Christian Brauner
2024-01-15 18:18 ` [PATCH v9 18/25] security: Introduce key_post_create_or_update hook Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-01-15 18:18 ` [PATCH v9 19/25] integrity: Move integrity_kernel_module_request() to IMA Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-12 17:37 ` Stefan Berger
2024-02-12 17:56 ` Paul Moore
2024-02-12 20:28 ` Stefan Berger
2024-02-13 8:57 ` Roberto Sassu
2024-02-13 16:31 ` Stefan Berger
2024-02-15 9:29 ` Roberto Sassu
2024-01-15 18:18 ` [PATCH v9 20/25] ima: Move to LSM infrastructure Roberto Sassu
2024-01-16 18:57 ` Casey Schaufler
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:50 ` Christian Brauner
2024-02-12 17:45 ` Stefan Berger
2024-01-15 18:18 ` [PATCH v9 21/25] ima: Move IMA-Appraisal " Roberto Sassu
2024-01-16 19:03 ` Casey Schaufler
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:45 ` Christian Brauner
2024-01-15 18:18 ` [PATCH v9 22/25] evm: Move " Roberto Sassu
2024-02-08 3:18 ` Paul Moore
2024-02-09 9:48 ` Christian Brauner
2024-02-12 18:26 ` Stefan Berger
2024-01-15 18:18 ` [PATCH v9 23/25] evm: Make it independent from 'integrity' LSM Roberto Sassu
2024-01-16 19:39 ` Casey Schaufler
2024-02-08 3:18 ` Paul Moore
2024-02-12 19:13 ` Stefan Berger
2024-01-15 18:18 ` [PATCH v9 24/25] ima: " Roberto Sassu
2024-01-16 19:40 ` Casey Schaufler
2024-02-12 19:47 ` Stefan Berger
2024-01-15 18:18 ` [PATCH v9 25/25] integrity: Remove LSM Roberto Sassu
2024-01-16 19:41 ` Casey Schaufler
2024-02-08 3:18 ` Paul Moore
2024-02-12 19:50 ` Stefan Berger
2024-02-08 3:18 ` [PATCH v9 0/25] security: Move IMA and EVM to the LSM infrastructure Paul Moore
2024-02-08 8:05 ` Roberto Sassu [this message]
2024-02-08 14:16 ` Paul Moore
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=dd8a979df500489c0d8595f9a3f89c801ce6f1c2.camel@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=Dai.Ngo@oracle.com \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=chuck.lever@oracle.com \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eparis@parisplace.org \
--cc=eric.snowberg@oracle.com \
--cc=jarkko@kernel.org \
--cc=jlayton@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=kolga@netapp.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=neilb@suse.de \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=tom@talpey.com \
--cc=viro@zeniv.linux.org.uk \
--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).