Re: [PATCH v15 00/11] LSM: Three basic syscalls
From: Paul Moore
Date: Wed Oct 18 2023 - 12:35:56 EST
On Wed, Oct 18, 2023 at 10:15 AM Roberto Sassu
<roberto.sassu@xxxxxxxxxxxxxxx> wrote:
> On 10/18/2023 3:09 PM, Mimi Zohar wrote:
...
> > I agree with Roberto. All three should be defined: LSM_ID_INTEGRITY,
> > LSM_ID_IMA, LSM_ID_EVM.
>
> I did not try yet, but the 'integrity' LSM does not need an LSM ID. With
> the last version adding hooks to 'ima' or 'evm', it should be sufficient
> to keep DEFINE_LSM(integrity) with the request to store a pointer in the
> security blob (even the init function can be a dummy function).
First off, this *really* should have been brought up way, way, *way*
before now. This patchset has been discussed for months, and bringing
up concerns in the eleventh hour is borderline rude.
At least we haven't shipped this in a tagged release from Linus yet,
so there is that.
If you want to add a unique LSM ID for both IMA and EVM, I'm okay with
that, but if we do that I don't see the need for a dedicated ID for
"integrity". Roberto, Mimi, one of you please send me a patch on top
of lsm/next-queue that updates the LSM ID to look like the following
(I believe EVM was added between AppArmor and Yama, yes?):
#define LSM_ID_UNDEF 0
#define LSM_ID_CAPABILITY 100
#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_EVM 106
#define LSM_ID_YAMA 107
#define LSM_ID_LOADPIN 108
#define LSM_ID_SAFESETID 109
#define LSM_ID_LOCKDOWN 110
#define LSM_ID_BPF 111
#define LSM_ID_LANDLOCK 112
... and also update the LSM registration code for IMA/EVM/etc. to do
the right thing.
Also, just to be clear, you should get this patch out ASAP.
--
paul-moore.com