Re: [PATCH v5 02/14] lockdown: Make the relationship to MODULE_SIG a dependency

Re: [PATCH v5 02/14] lockdown: Make the relationship to MODULE_SIG a dependency

[Nicolas Bouchinet]

> > diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
> > index e84ddf4840101..155959205b8ea 100644
> > --- a/security/lockdown/Kconfig
> > +++ b/security/lockdown/Kconfig
> > @@ -1,7 +1,7 @@
> >  config SECURITY_LOCKDOWN_LSM
> >  	bool "Basic module for enforcing kernel lockdown"
> >  	depends on SECURITY
> > -	select MODULE_SIG if MODULES
> > +	depends on !MODULES || MODULE_SIG
> 
> Will this change silently disable CONFIG_SECURITY_LOCKDOWN_LSM in existing
> defconfigs?
> 
> Because Kconfig's savedefconfig strips out automatically selected symbols,
> many in-tree defconfigs contain CONFIG_SECURITY_LOCKDOWN_LSM=y but omit
> CONFIG_MODULE_SIG=y. Since CONFIG_MODULE_SIG has no default y, it will
> initialize to n.
> 
> With CONFIG_MODULES=y and CONFIG_MODULE_SIG=n, this new dependency evaluates
> to n. As a result, Kconfig will drop CONFIG_SECURITY_LOCKDOWN_LSM from the
> final configuration without any warnings, leaving the kernel unprotected by
> lockdown. This also degrades discoverability, hiding the Lockdown LSM in
> menuconfig unless a user explicitly enables MODULE_SIG first.

I think the bot is correct, powerpc/configs/skiroot_defconfig,
powerpc/configs/ppc64_defconfig, s390/configs/debug_defconfig and
s390/configs/defconfig all set CONFIG_SECURITY_LOCKDOWN_LSM{,_EARLY}=y.
They also set CONFIG_MODULE_SIG_FORCE=y but do not set CONFIG_MODULE_SIG
directly. The new 'depends on' condition will thus evict
CONFIG_SECURITY_LOCKDOWN_LSM{,_EARLY} from the generated .config.

Nicolas