From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
Petr Tesarik <petrtesarik@huaweicloud.com>,
Paul Moore <paul@paul-moore.com>
Cc: 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, dhowells@redhat.com,
jarkko@kernel.org, stephen.smalley.work@gmail.com,
eparis@parisplace.org, mic@digikod.net,
linux-fsdevel@vger.kernel.org, linux-kernel@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, Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed blob for integrity_iint_cache
Date: Fri, 1 Dec 2023 00:43:28 +0100 [thread overview]
Message-ID: <9c7860ed-b761-417b-a9ad-bd680f2c8d16@huaweicloud.com> (raw)
In-Reply-To: <018438d4-44b9-4734-9c0c-8a65f9c605a4@schaufler-ca.com>
On 12/1/2023 12:31 AM, Casey Schaufler wrote:
> On 11/30/2023 1:34 PM, Roberto Sassu wrote:
>> On 11/30/2023 5:15 PM, Casey Schaufler wrote:
>>> On 11/30/2023 12:30 AM, Petr Tesarik wrote:
>>>> Hi all,
>>>>
>>>> On 11/30/2023 1:41 AM, Casey Schaufler wrote:
>>>>> ...
>>>>> It would be nice if the solution directly addresses the problem.
>>>>> EVM needs to be after the LSMs that use xattrs, not after all LSMs.
>>>>> I suggested LSM_ORDER_REALLY_LAST in part to identify the notion as
>>>>> unattractive.
>>>> Excuse me to chime in, but do we really need the ordering in code?
>>>
>>> tl;dr - Yes.
>>>
>>>> FWIW
>>>> the linker guarantees that objects appear in the order they are seen
>>>> during the link (unless --sort-section overrides that default, but this
>>>> option is not used in the kernel). Since *.a archive files are used in
>>>> kbuild, I have also verified that their use does not break the
>>>> assumption; they are always created from scratch.
>>>>
>>>> In short, to enforce an ordering, you can simply list the corresponding
>>>> object files in that order in the Makefile. Of course, add a big fat
>>>> warning comment, so people understand the order is not arbitrary.
>>>
>>> Not everyone builds custom kernels.
>>
>> Sorry, I didn't understand your comment.
>
> Most people run a disto supplied kernel. If the LSM ordering were determined
> only at compile time you could never run a kernel that omitted an LSM.
Ah, ok. We are talking about the LSMs with order LSM_ORDER_LAST which
are always enabled and the last.
This is the code in security.c to handle them:
/* LSM_ORDER_LAST is always last. */
for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
if (lsm->order == LSM_ORDER_LAST)
append_ordered_lsm(lsm, " last");
}
Those LSMs are not affected by lsm= in the kernel command line, or the
order in the kernel configuration (those are the mutable LSMs).
In this case, clearly, what matters is how LSMs are stored in the
.lsm_info.init section. See the DEFINE_LSM() macro:
#define DEFINE_LSM(lsm) \
static struct lsm_info __lsm_##lsm \
__used __section(".lsm_info.init") \
__aligned(sizeof(unsigned long))
With Petr, we started to wonder if somehow the order in which LSMs are
placed in this section is deterministic. I empirically tried to swap the
order in which IMA and EVM are compiled in the Makefile, and that led to
'evm' being placed in the LSM list before 'ima'.
The question is if this behavior is deterministic, or there is a case
where 'evm' is before 'ima', despite they are in the inverse order in
the Makefile.
Petr looked at the kernel linking process, which is relevant for the
order of LSMs in the .lsm_info.init section, and he found that the order
in the section always corresponds to the order in the Makefile.
Thanks
Roberto
>> Everyone builds the kernel, also Linux distros. What Petr was
>> suggesting was that it does not matter how you build the kernel, the
>> linker will place the LSMs in the order they appear in the Makefile.
>> And for this particular case, we have:
>>
>> obj-$(CONFIG_IMA) += ima/
>> obj-$(CONFIG_EVM) += evm/
>>
>> In the past, I also verified that swapping these two resulted in the
>> swapped order of LSMs. Petr confirmed that it would always happen.
>
> LSM execution order is not based on compilation order. It is specified
> by CONFIG_LSM, and may be modified by the LSM_ORDER value. I don't
> understand why the linker is even being brought into the discussion.
>
>>
>> Thanks
>>
>> Roberto
next prev parent reply other threads:[~2023-11-30 23:44 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 13:39 [PATCH v5 00/23] security: Move IMA and EVM to the LSM infrastructure Roberto Sassu
2023-11-07 13:39 ` [PATCH v5 01/23] ima: Align ima_inode_post_setattr() definition with " Roberto Sassu
2023-11-07 17:21 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 02/23] ima: Align ima_file_mprotect() " Roberto Sassu
2023-11-07 17:22 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 03/23] ima: Align ima_inode_setxattr() " Roberto Sassu
2023-11-07 17:23 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 04/23] ima: Align ima_inode_removexattr() " Roberto Sassu
2023-11-07 17:24 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 05/23] ima: Align ima_post_read_file() " Roberto Sassu
2023-11-07 17:25 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 06/23] evm: Align evm_inode_post_setattr() " Roberto Sassu
2023-11-07 17:26 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 07/23] evm: Align evm_inode_setxattr() " Roberto Sassu
2023-11-07 17:27 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 08/23] evm: Align evm_inode_post_setxattr() " Roberto Sassu
2023-11-07 17:28 ` Casey Schaufler
2023-11-07 13:39 ` [PATCH v5 09/23] security: Align inode_setattr hook definition with EVM Roberto Sassu
2023-11-07 13:39 ` [PATCH v5 10/23] security: Introduce inode_post_setattr hook Roberto Sassu
2023-11-07 17:30 ` Casey Schaufler
2023-11-16 4:33 ` Paul Moore
2023-11-16 9:43 ` Roberto Sassu
2023-11-16 18:46 ` Paul Moore
2023-11-07 13:40 ` [PATCH v5 11/23] security: Introduce inode_post_removexattr hook Roberto Sassu
2023-11-07 17:33 ` Casey Schaufler
2023-11-07 17:45 ` Roberto Sassu
2023-11-20 17:31 ` Roberto Sassu
2023-11-20 18:03 ` Casey Schaufler
2023-11-20 20:55 ` Paul Moore
2023-11-16 4:33 ` Paul Moore
2023-11-07 13:40 ` [PATCH v5 12/23] security: Introduce file_post_open hook Roberto Sassu
2023-11-07 17:35 ` Casey Schaufler
2023-11-07 13:40 ` [PATCH v5 13/23] security: Introduce file_pre_free_security hook Roberto Sassu
2023-11-07 17:39 ` Casey Schaufler
2023-11-16 4:33 ` Paul Moore
2023-11-16 9:46 ` Roberto Sassu
2023-11-16 18:41 ` Paul Moore
2023-11-07 13:40 ` [PATCH v5 14/23] security: Introduce path_post_mknod hook Roberto Sassu
2023-11-07 17:41 ` Casey Schaufler
2023-11-07 13:40 ` [PATCH v5 15/23] security: Introduce inode_post_create_tmpfile hook Roberto Sassu
2023-11-07 17:42 ` Casey Schaufler
2023-11-16 4:33 ` Paul Moore
2023-11-07 13:40 ` [PATCH v5 16/23] security: Introduce inode_post_set_acl hook Roberto Sassu
2023-11-07 17:44 ` Casey Schaufler
2023-11-16 4:33 ` Paul Moore
2023-11-07 13:40 ` [PATCH v5 17/23] security: Introduce inode_post_remove_acl hook Roberto Sassu
2023-11-07 17:45 ` Casey Schaufler
2023-11-16 4:33 ` Paul Moore
2023-11-07 13:40 ` [PATCH v5 18/23] security: Introduce key_post_create_or_update hook Roberto Sassu
2023-11-07 17:47 ` Casey Schaufler
2023-11-07 13:40 ` [PATCH v5 19/23] ima: Move to LSM infrastructure Roberto Sassu
2023-11-07 17:52 ` Casey Schaufler
2023-11-07 13:40 ` [PATCH v5 20/23] ima: Move IMA-Appraisal " Roberto Sassu
2023-11-07 18:43 ` Casey Schaufler
2023-11-07 13:40 ` [PATCH v5 21/23] evm: Move " Roberto Sassu
2023-11-07 18:45 ` Casey Schaufler
2023-11-07 13:40 ` [PATCH v5 22/23] integrity: Move integrity functions to the " Roberto Sassu
2023-11-07 18:46 ` Casey Schaufler
2023-11-16 4:33 ` Paul Moore
2023-11-16 10:07 ` Roberto Sassu
2023-11-17 21:22 ` Paul Moore
2023-11-20 13:23 ` Roberto Sassu
2023-11-07 13:40 ` [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed blob for integrity_iint_cache Roberto Sassu
2023-11-17 20:57 ` Paul Moore
2023-11-20 8:16 ` Roberto Sassu
2023-11-20 21:06 ` Paul Moore
2023-11-29 12:27 ` Roberto Sassu
2023-11-29 13:58 ` Roberto Sassu
2023-11-29 17:22 ` Paul Moore
2023-11-29 18:46 ` Roberto Sassu
2023-11-30 0:41 ` Casey Schaufler
2023-11-30 8:30 ` Petr Tesarik
2023-11-30 16:15 ` Casey Schaufler
2023-11-30 21:34 ` Roberto Sassu
2023-11-30 23:31 ` Casey Schaufler
2023-11-30 23:43 ` Roberto Sassu [this message]
2023-12-01 0:12 ` Casey Schaufler
2023-11-30 11:12 ` Mimi Zohar
2023-11-30 16:59 ` Paul Moore
2023-11-30 17:00 ` Paul Moore
2023-11-30 16:34 ` Paul Moore
2023-11-30 21:56 ` Roberto Sassu
2023-12-04 13:26 ` Roberto Sassu
2023-12-04 15:01 ` Mimi Zohar
2023-12-06 13:10 ` Roberto Sassu
2023-12-06 16:11 ` Mimi Zohar
2023-12-06 16:50 ` Roberto Sassu
2023-12-01 1:05 ` Dr. Greg
2023-12-01 18:54 ` Casey Schaufler
2023-12-01 23:53 ` Dr. Greg
2023-12-02 0:17 ` Casey Schaufler
2023-12-13 10:45 ` Roberto Sassu
2023-12-13 18:08 ` Casey Schaufler
2023-11-07 14:05 ` [PATCH v5 00/23] security: Move IMA and EVM to the LSM infrastructure Roberto Sassu
2023-11-07 19:37 ` Mimi Zohar
2023-11-08 3:14 ` 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=9c7860ed-b761-417b-a9ad-bd680f2c8d16@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=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-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=petrtesarik@huaweicloud.com \
--cc=roberto.sassu@huawei.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).