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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y1olXIbTGx9NnthU@kroah.com>
Date:   Thu, 27 Oct 2022 08:29:48 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     casey.schaufler@...el.com, paul@...l-moore.com,
        linux-security-module@...r.kernel.org, jmorris@...ei.org,
        keescook@...omium.org, john.johansen@...onical.com,
        penguin-kernel@...ove.sakura.ne.jp, stephen.smalley.work@...il.com,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        mic@...ikod.net
Subject: Re: [PATCH v1 4/8] LSM: Maintain a table of LSM attribute data

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@...aufler-ca.com>
> >> ---
> >>  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