Re: [PATCH v1 4/8] LSM: Maintain a table of LSM attribute data

[Greg KH]

On Wed, Oct 26, 2022 at 05:38:21PM -0700, Casey Schaufler wrote:
> On 10/25/2022 11:00 PM, Greg KH wrote:
> > On Tue, Oct 25, 2022 at 11:45:15AM -0700, Casey Schaufler wrote:
> >> As LSMs are registered add their lsm_id pointers to a table.
> >> This will be used later for attribute reporting.
> >>
> >> Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx>
> >> ---
> >>  include/linux/security.h | 17 +++++++++++++++++
> >>  security/security.c      | 18 ++++++++++++++++++
> >>  2 files changed, 35 insertions(+)
> >>
> >> diff --git a/include/linux/security.h b/include/linux/security.h
> >> index ca1b7109c0db..e1678594d983 100644
> >> --- a/include/linux/security.h
> >> +++ b/include/linux/security.h
> >> @@ -138,6 +138,23 @@ enum lockdown_reason {
> >>  
> >>  extern const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1];
> >>  
> >> +#define LSMID_ENTRIES ( \
> >> +	1 + /* capabilities */ \
> > No #define for capabilities?
> 
> Nope. There isn't one. CONFIG_SECURITY takes care of it.
> 
> >> +	(IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
> >> +	(IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
> >> +
> >> +extern int lsm_id;
> > u64?
> 
> u32. I doubt we'll get more than 32K security modules.

These should be bits, not values, right?

Wait, this magic entry value is going to change depeneding on what is,
or is not, enabled.  How is that a stable user/kernel api at all?

confused.

greg k-h