Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

On 10/25/2023 3:14 PM, Paul Moore wrote:
> On Wed, Oct 25, 2023 at 6:36 AM Roberto Sassu
> <roberto.sassu@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@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@paul-moore.com>
>>>>>>> Reviewed-by: Roberto Sassu <roberto.sassu@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.

Roberto