On Mon, Oct 17, 2022 at 11:26:44AM +0200, Mickaël Salaün wrote: > > On 14/10/2022 19:59, Kees Cook wrote: > > On Fri, Oct 14, 2022 at 04:40:01PM +0200, Mickaël Salaün wrote: > > > This is not backward compatible > > > > Why? Nothing will be running LSM hooks until init finishes, at which > > point the integrity inode cache will be allocated. And ima and evm don't > > start up until lateinit. > > > > > , but can easily be fixed thanks to > > > DEFINE_LSM().order > > > > That forces the LSM to be enabled, which may not be desired? > > This is not backward compatible because currently IMA is enabled > independently of the "lsm=" cmdline, which means that for all installed > systems using IMA and also with a custom "lsm=" cmdline, updating the kernel > with this patch will (silently) disable IMA. Using ".order = > LSM_ORDER_FIRST," should keep this behavior. > > BTW, I think we should set such order (but maybe rename it) for LSMs that do > nothing unless configured (e.g. Yama, Landlock). Ah yeah, good point. the .enabled stuff will need to be correctly wired up. Anyway, it's a good starting point for the conversion, so I'm hoping it can be carried forward by someone who is not me. :) (Hint hint to the integrity folks...) > > > Side node: I proposed an alternative to that but it was Nacked: > > > https://lore.kernel.org/all/20210222150608.808146-1-mic@xxxxxxxxxxx/ > > > > Yeah, for the reasons pointed out -- that can't work. The point is to > > not have The Default LSM. I do think Casey's NAK was rather prickly, > > though. ;) > > I don't agree, there is no "the default LSM", and this new behavior is under > an LSM_AUTO configuration option. The "config it twice" aspect of the current situation is suboptimal, yes. Let me go comment on the old thread... -- Kees Cook
