Received-SPF: pass (google.com: domain of linux-nfs+bounces-242-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <57ffb3ab-c877-4898-b01f-d146d6314b22@schaufler-ca.com>
Date: Thu, 30 Nov 2023 16:12:18 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed
 blob for integrity_iint_cache
Content-Language: en-US
To: Roberto Sassu <roberto.sassu@huaweicloud.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>,
 Casey Schaufler <casey@schaufler-ca.com>
References: <20231107134012.682009-24-roberto.sassu@huaweicloud.com>
 <17befa132379d37977fc854a8af25f6d.paul@paul-moore.com>
 <2084adba3c27a606cbc5ed7b3214f61427a829dd.camel@huaweicloud.com>
 <CAHC9VhTTKac1o=RnQadu2xqdeKH8C_F+Wh4sY=HkGbCArwc8JQ@mail.gmail.com>
 <b6c51351be3913be197492469a13980ab379e412.camel@huaweicloud.com>
 <CAHC9VhSAryQSeFy0ZMexOiwBG-YdVGRzvh58=heH916DftcmWA@mail.gmail.com>
 <90eb8e9d-c63e-42d6-b951-f856f31590db@huaweicloud.com>
 <366a6e5f-d43d-4266-8421-a8a05938a8fd@schaufler-ca.com>
 <66ec6876-483a-4403-9baa-487ebad053f2@huaweicloud.com>
 <a121c359-03c9-42b1-aa19-1e9e34f6a386@schaufler-ca.com>
 <9297638a-8dab-42ba-8b60-82c03497c9cd@huaweicloud.com>
 <018438d4-44b9-4734-9c0c-8a65f9c605a4@schaufler-ca.com>
 <9c7860ed-b761-417b-a9ad-bd680f2c8d16@huaweicloud.com>
From: Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <9c7860ed-b761-417b-a9ad-bd680f2c8d16@huaweicloud.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 11/30/2023 3:43 PM, Roberto Sassu wrote:
> 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.

OK, that's staring to make sense. My recollection is that there wasn't
an expectation for multiple LSM_ORDER_FIRST or LSM_ORDER_LAST entries
in the beginning. They were supposed to be special cases, not general
features.

>
> 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
>