[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 at 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 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) + \
> 
> 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