Messages in this thread | | | From | Paul Moore <> | Date | Wed, 18 Oct 2023 12:35:38 -0400 | Subject | Re: [PATCH v15 00/11] LSM: Three basic syscalls |
| |
On Wed, Oct 18, 2023 at 10:15 AM Roberto Sassu <roberto.sassu@huaweicloud.com> 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
| |