On 2/22/2021 1:12 PM, Nicolas Iooss wrote: > On Mon, Feb 22, 2021 at 9:32 PM Casey Schaufler <ca...@schaufler-ca.com> > wrote: >> On 2/22/2021 10:31 AM, Mickaël Salaün wrote: >>> On 22/02/2021 17:51, Casey Schaufler wrote: >>>> On 2/22/2021 7:06 AM, Mickaël Salaün wrote: >>>>> From: Mickaël Salaün <m...@linux.microsoft.com> >>>>> >>>>> Add a new option CONFIG_LSM_AUTO to enable users to delegate default LSM >>>>> stacking order to kernel developers. This enable to keep a consistent >>>>> order of enabled LSM when changing the LSM selection, especially when a >>>>> new LSM is added to the kernel. >>>> TL;DR - NAK >>>> >>>> Do you think that we might have considered this when stacking was >>>> introduced? >>> I didn't dig the detailed history of LSM stacking, but you are in Cc >>> because I know that you know. I may have though that the main goal of >>> the current LSM stacking implementation was to enable to stack existing >>> LSMs, which works well with this CONFIG_LSM list, but doesn't work as >>> well for new LSMs. >> It works just fine for new LSMs if you treat them as significant >> features which may have significant impact on the behavior of the >> system. >> >>>> Did you even consider the implications before sending >>>> the patch? >>> Yes, and it doesn't change much the current behavior without user >>> interaction. However, it gives the choice to users to choose how they >>> want their configuration to evolve. >> Automatic inclusions of new LSMs would be counter to existing practice. >> It won't work for "major" LSMs. >> >> >>>> This only makes any sense if you want to compile in >>>> AppArmor and/or Smack but always use SELinux. The existing Kconfig >>>> model handles that perfectly well. >>> This patch series doesn't change this behavior if the user doesn't want >>> it to change. >> Well, there's the question. If a distribution/system uses the new scheme >> "users" are going to get new LSMs spontaniously. If they don't it's up to >> the "user". Unsophisticated users won't want this, and the others don't >> need it. > Hello, sorry if I missed something simple but I did not understand > what "Automatic inclusions of new LSMs " and "get new LSMs > spontaniously" is about. If I understood the kernel practice > development correctly, when a new LSM will be included, it will have a > dedicated "config SECURITY_MYNEWLSM" which will be default to "n" in > order to respect the "principle of least astonishment". How could such > a new LSM be automatically/spontaneously added to the LSM list?
It wouldn't. But compiling the new LSM mynewlsm doesn't add it to the list, either. Today no one should expect a LSM to be active if it hasn't been added to the CONFIG_LSM list. The proposed addition of CONFIG_LSM_AUTO would change that. "make oldconfig" would add security modules that are built to the list. This is unnecessary since whoever changed CONFIG_SECURITY_MYNEWLSM to "y" could easily have added it to CONFIG_LSM. In the right place. > I understand that this is a tough issue and that the subject might > have been discussed a few years ago, and if that's the case, it would > be nice to have pointers to some clear documentation or past emails > (and it would be very very nice if the kernel documentation was > updated to document the current state of LSM stacking: I'm not going to argue against that. > for example > https://www.kernel.org/doc/html/v5.11/admin-guide/LSM/index.html still > documents the "security=" kernel parameter even though it conflicts > with CONFIG_LSM and can be ignored by the kernel in practise). You can still select one "major" module using security= if you don't use lsm= to specify a full list. We put real effort into being backward compatible. > > Thanks, > Nicolas >
