[PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

On 10/23/2023 6:11 PM, Roberto Sassu wrote:
> On 10/23/2023 5:48 PM, Casey Schaufler 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.
> 
> Yes, at the moment there is data in common, and we would need to check 
> case-by-case. Would be good to do after moving IMA and EVM to the LSM 
> infrastructure.

Paul, do you plan to upload this patch to your repo soon?

In this way, I reference your commit for applying my patches to move IMA 
and EVM to the LSM infrastructure.

Thanks

Roberto