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
