[PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

On 10/25/2023 4:06 PM, Roberto Sassu wrote:
> On 10/25/2023 3:14 PM, Paul Moore wrote:
>> On Wed, Oct 25, 2023 at 6:36 AM Roberto Sassu
>> <roberto.sassu at huaweicloud.com> wrote:
>>> On 10/24/2023 11:18 PM, Paul Moore wrote:
>>>> On Mon, Oct 23, 2023 at 11:48 AM Casey Schaufler 
>>>> <casey at schaufler-ca.com> wrote:
>>>>> On 10/23/2023 8:20 AM, Roberto Sassu wrote:
>>>>>> On 10/20/2023 11:56 PM, Casey Schaufler wrote:
>>>>>>> On 10/19/2023 1:08 AM, Roberto Sassu wrote:
>>>>>>>> On Wed, 2023-10-18 at 17:50 -0400, Paul Moore wrote:
>>>>>>>>> When IMA becomes a proper LSM we will reintroduce an appropriate
>>>>>>>>> LSM ID, but drop it from the userspace API for now in an effort
>>>>>>>>> to put an end to debates around the naming of the LSM ID macro.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Paul Moore <paul at paul-moore.com>
>>>>>>>> Reviewed-by: Roberto Sassu <roberto.sassu at huawei.com>
>>>>>>>>
>>>>>>>> This makes sense according to the new goal of making 'ima' and 
>>>>>>>> 'evm' as
>>>>>>>> standalone LSMs.
>>>>>>>>
>>>>>>>> Otherwise, if we took existing LSMs, we should have defined
>>>>>>>> LSM_ID_INTEGRITY, associated to DEFINE_LSM(integrity).
>>>>>>>>
>>>>>>>> If we proceed with the new direction, I will add the new LSM IDs as
>>>>>>>> soon as IMA and EVM become LSMs.
>>>>>>>
>>>>>>> This seems right to me. Thank You.
>>>>>>
>>>>>> Perfect! Is it fine to assign an LSM ID to 'ima' and 'evm' and keep
>>>>>> the 'integrity' LSM to reserve space in the security blob without LSM
>>>>>> ID (as long as it does not register any hook)?
>>>>>
>>>>> That will work, although it makes me wonder if all the data in the 
>>>>> 'integrity' blob
>>>>> is used by both IMA and EVM. If these are going to be separate LSMs 
>>>>> they should probably
>>>>> have their own security blobs. If there is data in common then an 
>>>>> 'integrity' blob can
>>>>> still makes sense.
>>>>
>>>> Users interact with IMA and EVM, not the "integrity" layer, yes?  If
>>>> so, I'm not sure it makes sense to have an "integrity" LSM, we should
>>>> just leave it at "IMA" and "EVM".
>>>
>>> The problem is who reserves and manages the shared integrity metadata.
>>> For now, it is still the 'integrity' LSM. If not, it would be IMA or EVM
>>> on behalf of the other (depending on which ones are enabled). Probably
>>> the second would not be a good idea.
>>
>> I'm not certain that managing kernel metadata alone necessitates a LSM
>> ID token value.  Does "integrity" have any user visible "things" that
>> it would want to expose to userspace?
> 
> No, it doesn't. I already moved the LSM hook registration to 'ima' and 
> 'evm'. Also the old 'integrity' initialization is done by 'ima' and 'evm'.
> 
> DEFINE_LSM(integrity) exists only to reserve space in the security blob 
> and to provide the security blob offset to the get/set functions.
> 
> Maybe I send the patch set, so that you get a better idea.

Uhm, we should have updated security.c and removed:

         (IS_ENABLED(CONFIG_IMA) ? 1 : 0) + \

Roberto