[PATCH] lsm: drop LSM_ID_IMA

[PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

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>
---
 include/uapi/linux/lsm.h | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
index eeda59a77c02..f0386880a78e 100644
--- a/include/uapi/linux/lsm.h
+++ b/include/uapi/linux/lsm.h
@@ -54,14 +54,13 @@ struct lsm_ctx {
 #define LSM_ID_SELINUX		101
 #define LSM_ID_SMACK		102
 #define LSM_ID_TOMOYO		103
-#define LSM_ID_IMA		104
-#define LSM_ID_APPARMOR		105
-#define LSM_ID_YAMA		106
-#define LSM_ID_LOADPIN		107
-#define LSM_ID_SAFESETID	108
-#define LSM_ID_LOCKDOWN		109
-#define LSM_ID_BPF		110
-#define LSM_ID_LANDLOCK		111
+#define LSM_ID_APPARMOR		104
+#define LSM_ID_YAMA		105
+#define LSM_ID_LOADPIN		106
+#define LSM_ID_SAFESETID	107
+#define LSM_ID_LOCKDOWN		108
+#define LSM_ID_BPF		109
+#define LSM_ID_LANDLOCK		110
 
 /*
  * LSM_ATTR_XXX definitions identify different LSM attributes
-- 
2.42.0

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

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.

Roberto

> ---
>  include/uapi/linux/lsm.h | 15 +++++++--------
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> index eeda59a77c02..f0386880a78e 100644
> --- a/include/uapi/linux/lsm.h
> +++ b/include/uapi/linux/lsm.h
> @@ -54,14 +54,13 @@ struct lsm_ctx {
>  #define LSM_ID_SELINUX		101
>  #define LSM_ID_SMACK		102
>  #define LSM_ID_TOMOYO		103
> -#define LSM_ID_IMA		104
> -#define LSM_ID_APPARMOR		105
> -#define LSM_ID_YAMA		106
> -#define LSM_ID_LOADPIN		107
> -#define LSM_ID_SAFESETID	108
> -#define LSM_ID_LOCKDOWN		109
> -#define LSM_ID_BPF		110
> -#define LSM_ID_LANDLOCK		111
> +#define LSM_ID_APPARMOR		104
> +#define LSM_ID_YAMA		105
> +#define LSM_ID_LOADPIN		106
> +#define LSM_ID_SAFESETID	107
> +#define LSM_ID_LOCKDOWN		108
> +#define LSM_ID_BPF		109
> +#define LSM_ID_LANDLOCK		110
>  
>  /*
>   * LSM_ATTR_XXX definitions identify different LSM attributes

Re: [PATCH] lsm: drop LSM_ID_IMA

[Casey Schaufler]

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.

>
> Roberto
>
>> ---
>>  include/uapi/linux/lsm.h | 15 +++++++--------
>>  1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
>> index eeda59a77c02..f0386880a78e 100644
>> --- a/include/uapi/linux/lsm.h
>> +++ b/include/uapi/linux/lsm.h
>> @@ -54,14 +54,13 @@ struct lsm_ctx {
>>  #define LSM_ID_SELINUX		101
>>  #define LSM_ID_SMACK		102
>>  #define LSM_ID_TOMOYO		103
>> -#define LSM_ID_IMA		104
>> -#define LSM_ID_APPARMOR		105
>> -#define LSM_ID_YAMA		106
>> -#define LSM_ID_LOADPIN		107
>> -#define LSM_ID_SAFESETID	108
>> -#define LSM_ID_LOCKDOWN		109
>> -#define LSM_ID_BPF		110
>> -#define LSM_ID_LANDLOCK		111
>> +#define LSM_ID_APPARMOR		104
>> +#define LSM_ID_YAMA		105
>> +#define LSM_ID_LOADPIN		106
>> +#define LSM_ID_SAFESETID	107
>> +#define LSM_ID_LOCKDOWN		108
>> +#define LSM_ID_BPF		109
>> +#define LSM_ID_LANDLOCK		110
>>  
>>  /*
>>   * LSM_ATTR_XXX definitions identify different LSM attributes

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

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

Thanks

Roberto

>> Roberto
>>
>>> ---
>>>   include/uapi/linux/lsm.h | 15 +++++++--------
>>>   1 file changed, 7 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
>>> index eeda59a77c02..f0386880a78e 100644
>>> --- a/include/uapi/linux/lsm.h
>>> +++ b/include/uapi/linux/lsm.h
>>> @@ -54,14 +54,13 @@ struct lsm_ctx {
>>>   #define LSM_ID_SELINUX		101
>>>   #define LSM_ID_SMACK		102
>>>   #define LSM_ID_TOMOYO		103
>>> -#define LSM_ID_IMA		104
>>> -#define LSM_ID_APPARMOR		105
>>> -#define LSM_ID_YAMA		106
>>> -#define LSM_ID_LOADPIN		107
>>> -#define LSM_ID_SAFESETID	108
>>> -#define LSM_ID_LOCKDOWN		109
>>> -#define LSM_ID_BPF		110
>>> -#define LSM_ID_LANDLOCK		111
>>> +#define LSM_ID_APPARMOR		104
>>> +#define LSM_ID_YAMA		105
>>> +#define LSM_ID_LOADPIN		106
>>> +#define LSM_ID_SAFESETID	107
>>> +#define LSM_ID_LOCKDOWN		108
>>> +#define LSM_ID_BPF		109
>>> +#define LSM_ID_LANDLOCK		110
>>>   
>>>   /*
>>>    * LSM_ATTR_XXX definitions identify different LSM attributes

Re: [PATCH] lsm: drop LSM_ID_IMA

[Casey Schaufler]

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.

>
> Thanks
>
> Roberto
>
>>> Roberto
>>>
>>>> ---
>>>>   include/uapi/linux/lsm.h | 15 +++++++--------
>>>>   1 file changed, 7 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
>>>> index eeda59a77c02..f0386880a78e 100644
>>>> --- a/include/uapi/linux/lsm.h
>>>> +++ b/include/uapi/linux/lsm.h
>>>> @@ -54,14 +54,13 @@ struct lsm_ctx {
>>>>   #define LSM_ID_SELINUX        101
>>>>   #define LSM_ID_SMACK        102
>>>>   #define LSM_ID_TOMOYO        103
>>>> -#define LSM_ID_IMA        104
>>>> -#define LSM_ID_APPARMOR        105
>>>> -#define LSM_ID_YAMA        106
>>>> -#define LSM_ID_LOADPIN        107
>>>> -#define LSM_ID_SAFESETID    108
>>>> -#define LSM_ID_LOCKDOWN        109
>>>> -#define LSM_ID_BPF        110
>>>> -#define LSM_ID_LANDLOCK        111
>>>> +#define LSM_ID_APPARMOR        104
>>>> +#define LSM_ID_YAMA        105
>>>> +#define LSM_ID_LOADPIN        106
>>>> +#define LSM_ID_SAFESETID    107
>>>> +#define LSM_ID_LOCKDOWN        108
>>>> +#define LSM_ID_BPF        109
>>>> +#define LSM_ID_LANDLOCK        110
>>>>     /*
>>>>    * LSM_ATTR_XXX definitions identify different LSM attributes
>

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

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

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.

Roberto

>> Thanks
>>
>> Roberto
>>
>>>> Roberto
>>>>
>>>>> ---
>>>>>    include/uapi/linux/lsm.h | 15 +++++++--------
>>>>>    1 file changed, 7 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
>>>>> index eeda59a77c02..f0386880a78e 100644
>>>>> --- a/include/uapi/linux/lsm.h
>>>>> +++ b/include/uapi/linux/lsm.h
>>>>> @@ -54,14 +54,13 @@ struct lsm_ctx {
>>>>>    #define LSM_ID_SELINUX        101
>>>>>    #define LSM_ID_SMACK        102
>>>>>    #define LSM_ID_TOMOYO        103
>>>>> -#define LSM_ID_IMA        104
>>>>> -#define LSM_ID_APPARMOR        105
>>>>> -#define LSM_ID_YAMA        106
>>>>> -#define LSM_ID_LOADPIN        107
>>>>> -#define LSM_ID_SAFESETID    108
>>>>> -#define LSM_ID_LOCKDOWN        109
>>>>> -#define LSM_ID_BPF        110
>>>>> -#define LSM_ID_LANDLOCK        111
>>>>> +#define LSM_ID_APPARMOR        104
>>>>> +#define LSM_ID_YAMA        105
>>>>> +#define LSM_ID_LOADPIN        106
>>>>> +#define LSM_ID_SAFESETID    107
>>>>> +#define LSM_ID_LOCKDOWN        108
>>>>> +#define LSM_ID_BPF        109
>>>>> +#define LSM_ID_LANDLOCK        110
>>>>>      /*
>>>>>     * LSM_ATTR_XXX definitions identify different LSM attributes
>>

Re: [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@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.
> 
> 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

Re: [PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

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

-- 
paul-moore.com

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

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.

Thanks

Roberto

Re: [PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

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?

-- 
paul-moore.com

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

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

Re: [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@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.

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

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

Roberto

Re: [PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

On Wed, Oct 25, 2023 at 10:37 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
> 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@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.
>
> Uhm, we should have updated security.c and removed:
>
>          (IS_ENABLED(CONFIG_IMA) ? 1 : 0) + \

With LSM_CONFIG_COUNT only being used inside security_add_hooks() I
believe you are correct.  Do you want to send a patch against
lsm/dev-staging?

-- 
paul-moore.com

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

On Wed, 2023-10-25 at 22:54 -0400, Paul Moore wrote:
> On Wed, Oct 25, 2023 at 10:37 AM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > 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@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.
> > 
> > Uhm, we should have updated security.c and removed:
> > 
> >          (IS_ENABLED(CONFIG_IMA) ? 1 : 0) + \
> 
> With LSM_CONFIG_COUNT only being used inside security_add_hooks() I
> believe you are correct.  Do you want to send a patch against
> lsm/dev-staging?

Yes, will do.

Roberto

Re: [PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

On Wed, Oct 25, 2023 at 10:06 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
> 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.

If it isn't a big ask, sure, but I still need to get through the last
patchset you posted.  I do apologize for the delay on that, things
seem to be very busy recently.

-- 
paul-moore.com

Re: [PATCH] lsm: drop LSM_ID_IMA

[Roberto Sassu]

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

Question, it might be better to ensure that 'evm' is after 'ima' like 
when function calls were hardcoded.

I'm enforcing 'ima' and 'evm' to be the last.

In this case, since we have:

         /* 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");
         }

and:

obj-$(CONFIG_IMA)                       += ima/
obj-$(CONFIG_EVM)                       += evm/

in the integrity Makefile, can I assume that the order will always be 
'ima', 'evm'?

I tried to invert obj-, and indeed the order is inverted. They are not 
mutable LSMs, their order should not depend on the kernel command line. 
Right?

Thanks

Roberto

Re: [PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

On Thu, Oct 19, 2023 at 4:08 AM Roberto Sassu
<roberto.sassu@huaweicloud.com> 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>

Thanks.  I just merged this into lsm/next-queue.

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

Thank you.

-- 
paul-moore.com

Re: [PATCH] lsm: drop LSM_ID_IMA

[Paul Moore]

On Wed, Oct 18, 2023 at 5:50 PM Paul Moore <paul@paul-moore.com> 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>
> ---
>  include/uapi/linux/lsm.h | 15 +++++++--------
>  1 file changed, 7 insertions(+), 8 deletions(-)

Merged into lsm/dev.

-- 
paul-moore.com