On Wed, 2023-10-18 at 16:40 -0400, Paul Moore wrote: > On Wed, Oct 18, 2023 at 4:23 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Wed, 2023-10-18 at 12:35 -0400, Paul Moore wrote: > > > 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. > > > > As everyone knows IMA and EVM are not LSMs at this point. > > Considering all the work Roberto has been doing to make that happen, > not to mention the discussions we've had on this topic, that's an > awfully small technicality to use as the basis of an argument. Sorry Paul, but I've been working on this patch set for a long time and you were also involved in the prerequisites (like making the 'integrity' LSM as the last). I thought it was clear at this point that we were going to add the hooks to the 'integrity' LSM. I really have no problem to rebase my work on top of other work, but I was very surprised to see LSM_ID_IMA instead of LSM_ID_INTEGRITY, and at minimum this should have been agreed with Mimi. And also, I was not convinced with the argument that LSM_ID_IMA should represent IMA+EVM. Roberto
